GCC asm analysis (for NIR)

[ASVIEST]

Abstract

Analyse GCC extended asm and generate errors for an invalid code, also change some .

Motivation

Asm stategment does not allow you to write correct code (in some cases), so you have to resort to tricks

Description

It must be implemented when NIR will more complete.

Code Examples

proc test(a: int64) =
  asm """
    add %[val], %[a]
    :[a]"=r"(`a`)
    :[val]"r"((long long)(4/2))
  """

var a: int64 = 35
test(a)
echo a
# This code compiles (although it shouldn't because it tries to change a parameter)

proc test(a: var int64) =
  asm """
    add %[val], %[a]
    :[a]"=r"(`a`)
    :[val]"r"((long long)(4/2))
  """

var a: int64 = 35
test(a)
echo a
# Code compiles again, but again it doesn't change a (for C through GCC), or when
# compiling in C++ through GCC, `a` becomes random number.

It will possible to support via analysis.

Backwards Compatibility

No response

[mratsim]

I think it's less error-prone for users to use a DSL for inline assembly. Not to say that analysis isn't worthwhile, but it doesn't solve the problem that inline ASM is painful to write even if we're aware of the whole syntax.

GCC and Clang inline assembly even differ for memory operands.

See an example DSL here:

• https://github.com/mratsim/constantine/blob/641db76/constantine/platforms/isa/macro_assembler_x86_att.nim

And example usage for bigint multiplication:

• https://github.com/mratsim/constantine/blob/641db76/constantine/math/arithmetic/assembly/limbs_asm_mul_x86.nim

[Araq]

I still don't get the fixation on the inline assembler when not even "hello world" works with NIR. Priorities from outer space, sorry.