3 ms·

Tangential question, something I've always wanted to ask. The ISA here is given by example, here's a couple MOVE src, dst: dst := src ADD src, dst:

Tangential question, something I've always wanted to ask. The ISA here is given by example, here's a couple MOVE src, dst: dst := src ADD src, dst: dst := dst + src I have always wondered why assembler is written the first way MOVE src, dst ADD src, dst rather than the far more intuitive (and slightly more compact) second, something like dst := src dst += src This also completely eliminates questions about which direction data goes, is 'mov a,b' a:=b or b:=a for example. I can't see any reason for not using the established C-type notation, so why is the original style always perpetuated? I'm aware that C approximately maps onto the original PDP ISA and has been called a high-level assembler, true or not that's irrelevant, but why the higher-level syntax has never made its way to lower level ASM has baffled me.

gtirloni 7y ago
AT&T vs Intel syntax
Zardoz84 7y ago
It's Intel vs AT&T syntax : Intel: mov eax, 4 AT&T : movl $4, %eax One could interpret that doing ADD a, b, c would be "do a + b and put in c"
titzer 7y ago
It's very useful to have the actual instruction mnemonics spelled out, instead of relying on an implicit (often overloaded) definition of "+". E.g. there might be a 8-bit, 16-bit, 32-bit integer add, a 32-bit, 64-bit floating point add, a 16x8 vector integer add, etc.
- throwaway_pdp09 7y ago
  Hm, good point. How about a +=L b for a long type? Or have a non-annotated opcode for the native machine word size (just '+') and annotated for anything smaller (edit: anything other) - ('+B' for byte addition). An alternative and perhaps much better higher-level solution is to have typed ASM. I believe there is work done in this area (quick search gets http://www.cs.cornell.edu/talc/ http://www.cs.cornell.edu/talc/), which would allow the type to be implicit but checkably safe but for the occasional explicitly needed coercions.
deleted 7y ago
[deleted]
pjc50 7y ago
> why the higher-level syntax has never made its way to lower level ASM has baffled me Traditionally assembler was both for bootstrap processes and for the older heavily resource constrained systems, so there was a lot of emphasis on making it as simple to parse as possible; opcode first, then arguments, because the opcode is first in the byte stream of almost all variable-instruction length systems. And of course no support for complex expressions, so no point in building a full mathematic expression parser. Then there's the question of which add instruction you want. The vast proliferation of instructions in things like AVX gives you "VADDPS" and even "VFMSUBADD132PD", which expands to: https://www.felixcloutier.com/x86/vfmsubadd132pd:vfmsubadd213pd:vfmsubadd231pd https://www.felixcloutier.com/x86/vfmsubadd132pd:vfmsubadd21... IF (VEX.128) THEN DEST[63:0]←RoundFPControl_MXCSR(DEST[63:0]*SRC3[63:0] + SRC2[63:0]) DEST[127:64]←RoundFPControl_MXCSR(DEST[127:64]*SRC3[127:64] - SRC2[127:64]) DEST[MAXVL-1:128] ←0 ELSEIF (VEX.256) DEST[63:0]←RoundFPControl_MXCSR(DEST[63:0]*SRC3[63:0] + SRC2[63:0]) DEST[127:64]←RoundFPControl_MXCSR(DEST[127:64]*SRC3[127:64] - SRC2[127:64]) DEST[191:128]←RoundFPControl_MXCSR(DEST[191:128]*SRC3[191:128] + SRC2[191:128]) DEST[255:192]←RoundFPControl_MXCSR(DEST[255:192]*SRC3[255:192] - SRC2[255:192] FI VFMSUBADD213PD DEST, SRC2, SRC3 IF (VEX.128) THEN DEST[63:0]←RoundFPControl_MXCSR(SRC2[63:0]*DEST[63:0] + SRC3[63:0]) DEST[127:64]←RoundFPControl_MXCSR(SRC2[127:64]*DEST[127:64] - SRC3[127:64]) DEST[MAXVL-1:128] ←0 ELSEIF (VEX.256) DEST[63:0]←RoundFPControl_MXCSR(SRC2[63:0]*DEST[63:0] + SRC3[63:0]) DEST[127:64]←RoundFPControl_MXCSR(SRC2[127:64]*DEST[127:64] - SRC3[127:64]) DEST[191:128]←RoundFPControl_MXCSR(SRC2[191:128]*DEST[191:128] + SRC3[191:128]) DEST[255:192]←RoundFPControl_MXCSR(SRC2[255:192]*DEST[255:192] - SRC3[255:192] FI
- throwaway_pdp09 7y ago
  We don't have resource constrained systems now. I doubt parsing asm ever took up much anyway. I'm not suggesting we permit complex (ie. general opcode combination) expressions. I deliberately never suggested it. As to straighforward FMAC-type instructions, that's even clearer in my notation: a += b * c But As for the proliferation of those add types you linked to, OK, possibly valid, but how much of this are you going to be manually writing compared to the very mundane style non-simd non-packed instructions? My guess is very little as you have relatively few number of such instructions (although they're doing a great deal of work over streams of data, but that's not relevant).
pacman128 7y ago
Randall Hyde created a higher level assembler back in the 90's. It supported writing C like control statements, etc. It doesn't look like it has been updated to x86-64, still just 32-bit. https://en.wikipedia.org/wiki/High_Level_Assembly https://en.wikipedia.org/wiki/High_Level_Assembly
MaxBarraclough 7y ago
Your sense of which is intuitive, isn't universal. When we say Move this over there, it's left-to-right. > why the higher-level syntax has never made its way to lower level ASM has baffled me. It has. In the AT&T x86 assembly syntax, MOV is left-to-right. (In the Intel syntax, though, it's right-to-left.) https://en.wikipedia.org/w/index.php?title=X86_assembly_language&oldid=943655045#Syntax https://en.wikipedia.org/w/index.php?title=X86_assembly_lang...
- oso2k 7y ago
  I like to say that AT&T follows natural English flow and byte order of the finally assembled binary code. Intel followed the more mathematically oriented syntax. Might be a bit back duck syndrome since I learned math and Intel first, but Intel seemed more intuitive to me as well. AT&T ASM | English | Binary MOVE src, dst | src -> dst | 01 src dst ADD src, dst | src + dst -> dst | 02 src dst or src + dst = dst Compared to Intel ASM | English | Binary MOV dst, src | dst <- src | 01 dst src ADD dst, src | dst <- dst + src | 02 dst src or dst = dst + src dst += src <- could be read as `loaded from` -> could be read as `stored to` Notice the RISC-y-ness of that. However, ISAs developed later and are primarily MIPS-like follow Intel convention and extend it because it aligns better with 3AC [0] SSA[1] based optimizations. [0] https://en.wikipedia.org/wiki/Three-address_code https://en.wikipedia.org/wiki/Three-address_code [1] https://en.wikipedia.org/wiki/Static_single_assignment_form https://en.wikipedia.org/wiki/Static_single_assignment_form

gtirloni 7y ago

AT&T vs Intel syntax

Zardoz84 7y ago

It's Intel vs AT&T syntax : Intel: mov eax, 4 AT&T : movl $4, %eax One could interpret that doing ADD a, b, c would be "do a + b and put in c"

titzer 7y ago

It's very useful to have the actual instruction mnemonics spelled out, instead of relying on an implicit (often overloaded) definition of "+". E.g. there might be a 8-bit, 16-bit, 32-bit integer add, a 32-bit, 64-bit floating point add, a 16x8 vector integer add, etc.

throwaway_pdp09 7y ago
Hm, good point. How about a +=L b for a long type? Or have a non-annotated opcode for the native machine word size (just '+') and annotated for anything smaller (edit: anything other) - ('+B' for byte addition). An alternative and perhaps much better higher-level solution is to have typed ASM. I believe there is work done in this area (quick search gets http://www.cs.cornell.edu/talc/ http://www.cs.cornell.edu/talc/), which would allow the type to be implicit but checkably safe but for the occasional explicitly needed coercions.

deleted 7y ago

[deleted]

pjc50 7y ago

> why the higher-level syntax has never made its way to lower level ASM has baffled me Traditionally assembler was both for bootstrap processes and for the older heavily resource constrained systems, so there was a lot of emphasis on making it as simple to parse as possible; opcode first, then arguments, because the opcode is first in the byte stream of almost all variable-instruction length systems. And of course no support for complex expressions, so no point in building a full mathematic expression parser. Then there's the question of which add instruction you want. The vast proliferation of instructions in things like AVX gives you "VADDPS" and even "VFMSUBADD132PD", which expands to: https://www.felixcloutier.com/x86/vfmsubadd132pd:vfmsubadd213pd:vfmsubadd231pd https://www.felixcloutier.com/x86/vfmsubadd132pd:vfmsubadd21... IF (VEX.128) THEN DEST[63:0]←RoundFPControl_MXCSR(DEST[63:0]*SRC3[63:0] + SRC2[63:0]) DEST[127:64]←RoundFPControl_MXCSR(DEST[127:64]*SRC3[127:64] - SRC2[127:64]) DEST[MAXVL-1:128] ←0 ELSEIF (VEX.256) DEST[63:0]←RoundFPControl_MXCSR(DEST[63:0]*SRC3[63:0] + SRC2[63:0]) DEST[127:64]←RoundFPControl_MXCSR(DEST[127:64]*SRC3[127:64] - SRC2[127:64]) DEST[191:128]←RoundFPControl_MXCSR(DEST[191:128]*SRC3[191:128] + SRC2[191:128]) DEST[255:192]←RoundFPControl_MXCSR(DEST[255:192]*SRC3[255:192] - SRC2[255:192] FI VFMSUBADD213PD DEST, SRC2, SRC3 IF (VEX.128) THEN DEST[63:0]←RoundFPControl_MXCSR(SRC2[63:0]*DEST[63:0] + SRC3[63:0]) DEST[127:64]←RoundFPControl_MXCSR(SRC2[127:64]*DEST[127:64] - SRC3[127:64]) DEST[MAXVL-1:128] ←0 ELSEIF (VEX.256) DEST[63:0]←RoundFPControl_MXCSR(SRC2[63:0]*DEST[63:0] + SRC3[63:0]) DEST[127:64]←RoundFPControl_MXCSR(SRC2[127:64]*DEST[127:64] - SRC3[127:64]) DEST[191:128]←RoundFPControl_MXCSR(SRC2[191:128]*DEST[191:128] + SRC3[191:128]) DEST[255:192]←RoundFPControl_MXCSR(SRC2[255:192]*DEST[255:192] - SRC3[255:192] FI

throwaway_pdp09 7y ago
We don't have resource constrained systems now. I doubt parsing asm ever took up much anyway. I'm not suggesting we permit complex (ie. general opcode combination) expressions. I deliberately never suggested it. As to straighforward FMAC-type instructions, that's even clearer in my notation: a += b * c But As for the proliferation of those add types you linked to, OK, possibly valid, but how much of this are you going to be manually writing compared to the very mundane style non-simd non-packed instructions? My guess is very little as you have relatively few number of such instructions (although they're doing a great deal of work over streams of data, but that's not relevant).

pacman128 7y ago

Randall Hyde created a higher level assembler back in the 90's. It supported writing C like control statements, etc. It doesn't look like it has been updated to x86-64, still just 32-bit. https://en.wikipedia.org/wiki/High_Level_Assembly https://en.wikipedia.org/wiki/High_Level_Assembly

MaxBarraclough 7y ago

Your sense of which is intuitive, isn't universal. When we say Move this over there, it's left-to-right. > why the higher-level syntax has never made its way to lower level ASM has baffled me. It has. In the AT&T x86 assembly syntax, MOV is left-to-right. (In the Intel syntax, though, it's right-to-left.) https://en.wikipedia.org/w/index.php?title=X86_assembly_language&oldid=943655045#Syntax https://en.wikipedia.org/w/index.php?title=X86_assembly_lang...

oso2k 7y ago
I like to say that AT&T follows natural English flow and byte order of the finally assembled binary code. Intel followed the more mathematically oriented syntax. Might be a bit back duck syndrome since I learned math and Intel first, but Intel seemed more intuitive to me as well. AT&T ASM | English | Binary MOVE src, dst | src -> dst | 01 src dst ADD src, dst | src + dst -> dst | 02 src dst or src + dst = dst Compared to Intel ASM | English | Binary MOV dst, src | dst <- src | 01 dst src ADD dst, src | dst <- dst + src | 02 dst src or dst = dst + src dst += src <- could be read as `loaded from` -> could be read as `stored to` Notice the RISC-y-ness of that. However, ISAs developed later and are primarily MIPS-like follow Intel convention and extend it because it aligns better with 3AC [0] SSA[1] based optimizations. [0] https://en.wikipedia.org/wiki/Three-address_code https://en.wikipedia.org/wiki/Three-address_code [1] https://en.wikipedia.org/wiki/Static_single_assignment_form https://en.wikipedia.org/wiki/Static_single_assignment_form