Everyone Says Assembly Is Untyped–Everyone Is Wrong

Krssst

Sorry, somewhat of a tangent but regarding: > The %0 and %1 are positional references into a list you have to count by hand. You can name your operands in gcc inline assembly. https://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html#Output-... Look for "asmSymbolicName". On a phone so not checking if it builds, but something like `asm("add %[my_out], %[my_in], #3":[my_out]"=r"(outvar):[my_in]"r"(invar):);`.

genxy

An avenuge of research worth being sniped on is Typed Assembly Language https://en.wikipedia.org/wiki/Typed_assembly_language https://www.cs.cornell.edu/talc/overview.html

magicalhippo

> But because of its time period, the built-in assembler only ever understood up to 80286 instructions, so the day you wanted a 386 and its 32-bit registers you were sent off to an external assembler anyway. Or you just prefixed the instructions with "db $66", et voila your instructions were 32bit. I wrote a lot of inline 32bit assembly that way in TP 6.0 and 7.0.

amluto

I have very mixed opinions about the custom syntax. IMO the correct asm syntax, with very few exceptions, is the one in the manual . This is why Intel syntax is right and AT&T syntax is wrong: the ISA comes from Intel, the docs are from Intel and AMD, and those docs use Intel syntax. So I was kind of hoping that the custom syntax would at least result in a very, very strong checker, at least as good as Fil-C’s. Maybe with an escape hatch to say something like “I know it looks like I clobbered xyz, but I promise I really didn’t. Sadly, the CPUID example in the article apparently compiles, but IMO it shouldn’t have: CPUID takes two inputs, in EAX and ECX, and the example forgot to bind ECX as an input. One might argue that CPUID takes even more inputs if you’re on a VM and doing something special, but ECX is really quite unambiguous.