4 ms·

Is macro assembly really assembly though? I clicked no because I claim that there’s a continuum of expressiveness between a macro assembler and a C compiler, wh

Is macro assembly really assembly though? I clicked no because I claim that there’s a continuum of expressiveness between a macro assembler and a C compiler, which makes it hard to draw a line. This is debatable of course, and I was hoping the article would go into some of this. Instead, the analysis seems to stop at “if it’s called assembly, it is assembly”, unfortunately. Edit: I suggest that as a necessary condition for something to be assembly, disassemble(assemble(x)) = x, modulo comments and label names.

archi42 5y ago
There is another commenter who kind of thinks that this should hold, but I've got to disappoint either of you: Most ISAs specify some pseudo ops, so might get something like disassemble(assemble("nop")) == "add r0, 0" I think that's how v850 or tricore do it. Than there is ARM, for which the v8.6 ISA manual casually contains the term "This instruction is an alias of" 115 times. (I checked the rev. F PDF, you can get the rev. G PDF at https://developer.arm.com/documentation/ddi0487/ga/ https://developer.arm.com/documentation/ddi0487/ga/ by clicking "Download").
- codeflo 5y ago
  I hope we agree that alternative mnemonics don't change anything essential about the code, so the equation "kind of" still holds. You have a point that it's hard to formulate this precisely.
  - archi42 5y ago
    Absolutely. I tried, but gave up and decided to spent my saturday morning with the familiy instead ;-) I think a huge problem is how it is easy to mix up assembly that gets "processed" to /machine/ instructions with another kind of assembly that gets "processed" to VM ops. Which then get compiled again (usually JIT) before being executed. ILAsm is a nice example for that: It's some kind of assembly language, and you could probably go right down to x86 instructions (at least with little change). But you'll never do that. Simply because it is a stack language; and while you can produce e.g. x86 opcodes that "do the right thing", the whole stack traffic will kill performance. Instead, the VM will push the opcode stream through a (I guess JIT?) compiler: Small functions will be inlined, others will get a prologe and epiloge, parameters and return values are arranged according to the ABI's calling conventions. And then there will be all the usual register allocation stuff. [edit] And a lot of other magic. [/edit] Still, the original input is pretty much an assembly language.

archi42 5y ago

There is another commenter who kind of thinks that this should hold, but I've got to disappoint either of you: Most ISAs specify some pseudo ops, so might get something like disassemble(assemble("nop")) == "add r0, 0" I think that's how v850 or tricore do it. Than there is ARM, for which the v8.6 ISA manual casually contains the term "This instruction is an alias of" 115 times. (I checked the rev. F PDF, you can get the rev. G PDF at https://developer.arm.com/documentation/ddi0487/ga/ https://developer.arm.com/documentation/ddi0487/ga/ by clicking "Download").

codeflo 5y ago
I hope we agree that alternative mnemonics don't change anything essential about the code, so the equation "kind of" still holds. You have a point that it's hard to formulate this precisely.
- archi42 5y ago
  Absolutely. I tried, but gave up and decided to spent my saturday morning with the familiy instead ;-) I think a huge problem is how it is easy to mix up assembly that gets "processed" to /machine/ instructions with another kind of assembly that gets "processed" to VM ops. Which then get compiled again (usually JIT) before being executed. ILAsm is a nice example for that: It's some kind of assembly language, and you could probably go right down to x86 instructions (at least with little change). But you'll never do that. Simply because it is a stack language; and while you can produce e.g. x86 opcodes that "do the right thing", the whole stack traffic will kill performance. Instead, the VM will push the opcode stream through a (I guess JIT?) compiler: Small functions will be inlined, others will get a prologe and epiloge, parameters and return values are arranged according to the ABI's calling conventions. And then there will be all the usual register allocation stuff. [edit] And a lot of other magic. [/edit] Still, the original input is pretty much an assembly language.