6 ms·

Why is assembly locked into an ocean of cryptic sequence of letters that no respectable dictionary will try to pretend to be a word? Or is there an assembly th

Why is assembly locked into an ocean of cryptic sequence of letters that no respectable dictionary will try to pretend to be a word? Or is there an assembly that get rid of this gibberish tradition?

okaleniuk 4y ago
I tried to make a readable assembly once: https://github.com/akalenuk/milasm https://github.com/akalenuk/milasm But apparently, this is not a win-win, but a lose-lose since this notation is hated by both assembly programmers and not assembly programmers :-D
- psychoslave 4y ago
  Interesting project, thanks for sharing. That seems to be a bit tangent to my remark though: this seems to be more about adding syntactic structures, embodied with miscellaneous brackets, and there are still some obfuscating abbreviations like "ldstr".
  - okaleniuk 4y ago
    Ah yes, but the whole point of the project is to go away from this: ldstr "Hello!" call void [mscorlib]System.Console::Write (string) And come to that: ((write: "Hello!")) So `ldstr` does indeed feature in the example but only as a "before" picture. But you're right, it is about adding syntactic features to the existing language.
userbinator 4y ago
Because it's its own language. Or is there an assembly that get rid of this gibberish tradition? Look up Randall Hyde's HLA. The famous author of various Asm books thought he could make a better syntax, and... almost no one wanted it.
pclmulqdq 4y ago
Assemblers for DSPs go so far as having arithmetic operators like "+" and "=" in their vocabulary, as well as allowing things like hierarchical braces as syntactic sugar if you want them. But you are intended to write assembly for them, so making it almost C-like has a lot of benefits. The real answer is that nobody is supposed to write assembly, and the way the instructions are written is very easy to parse. The only core that doesn't have the "it's ancient and we didn't know better" excuse is RISC-V, IMO.
mattashii 4y ago
A terse notation is useful for grokking code, as the information is spread across less characters that need to be interpreted by the brain. If you expanded all names, that would add cognitive overhead for all users and reduce the useful information per character, and potentially reduce the information that can fit on a screen significantly. While I'll agree that "cryptic sequences" are a more steep learning slope, they allow for much faster understanding of larger blocks of data/assembly once the "cryptic sequences" themselves are understood.
- keithalewis 4y ago
  Same reason people use APL inspired languages.
- psychoslave 4y ago
  >A terse notation is useful for grokking code Terse doesn’t necessarily mean opaque. Even if sticking to three letter words was an absolute requirement, there are plenty of English words that would make a better jobs at conducting the idea without falling into a collection of unpronounceable idiosyncratic terms. > as the information is spread across less characters that need to be interpreted by the brain. That’s not how the brain interpret text generally, once reading is fully acquired. Words, or even group of words are taken all together. Would it be for scriptural compactness alone, it would be far more efficient to use dedicated symbols optimized for that purpose. But if the idea is to optimize readability for an unknown large audience, then this is most likely a rather misguided choice. >If you expanded all names, that would add cognitive overhead for all users Well, I disagree. To my mind it would on the contrary significantly reduce cognitive load for those not already familiar with the uselessly abstruse terms, and add nothing to those already accustomed to code constructions in the machine specific language. >reduce the useful information per character Once again, this is a very poor metric for human interpretation of textual works. > potentially reduce the information that can fit on a screen significantly. So what? Number of signs displayed on the screen is certainly not the limiting factor here. How much juxtaposed signs a human attention can meaningfully handle is far more compelling. >they allow for much faster understanding of larger blocks of data/assembly once the "cryptic sequences" themselves are understood. I am not aware of any study that supports such a statement on empirical evidences. Maybe you can point me to such a study and help me change my mind? Assembly, back in the time of punched cards, had some reasonable rationals for avoiding input sequences longer than strictly necessary. Bu these rational no longer fit the contemporary digital landscape.
dj_mc_merlin 4y ago
You can just write your own assembler if you wish to. It's much easier than writing a full fledged compiler for a higher language, but that obviously doesn't make it easy. Otherwise, mnemonics are the way they are because of history, but also practicality. Since you're going to be writing them a lot, you want them to be short. It also doesn't take too long until their meanings are burned into your brain.
- deleted 4y ago
  [deleted]
chongli 4y ago
There are multiple real-world instruction sets that have a few dozen opcodes at most. Learning the mnemonics and operands for one of these ISAs can be done in an afternoon. Much easier than learning a really complicated language like C++ or Rust. The hard part about assembly language is its very limited abstraction. You’re only one step away from the metal. So it takes a lot of work to build a large program and it can be very tricky to get right because you don’t have a compiler or any types to help you. If you know what you’re doing, though, you can write some very small binaries!
- osobo 4y ago
  > You’re only one step away from the metal. You can write about assembly like a poet, at least.
  - deleted 4y ago
    [deleted]
- drpixie 4y ago
  Very true, though there are some instruction sets with literally thousands - like the Intel x86-64. Give me RISC any day.
  - mhh__ 4y ago
    RISC is probably hard to do for a big desktop chip. AArch64 is more like regular than reduced instruction set computing. Its a very big complicated ISA but also not a complete mess like X86. RISC-V is reduced by these standards but requires a very real instruction count penalty. The compressed ISA performs it's job admirably, do keep in mind, but I think it remains to be seen if some of the aggressively simple/clean aspects of risc-v end up hurting it.
  - deckard1 4y ago
    x86 doesn't have thousands. That's overstating it by quite a bit. The assembler I wrote contains 1095 encodings. It's from ~2004 but 100% complete at the time, so sure new instructions have been added since. But those are encodings. SAL has like 8 encodings, SAR has 12, CMP has 14, etc. These encodings are just different ways to use the same opcode but with different source/target parameters (8/16/32-bit immediates or registers, etc.) Someone wrote a script that disassembled all the binaries on their Linux machine and counted the number of actual instructions used (mostly by gcc, of course). Only a tiny fraction of the total instructions were used: http://0x80.pl/notesen/2014-01-01-instruction-utilization.html http://0x80.pl/notesen/2014-01-01-instruction-utilization.ht... Just take the top 30 of that chart and learn those. The x86 contains a lot of instructions that no one needs to worry about. Things related to the ancient segment mode or x87 floating point, OS-privileged instructions (context switching, HLT/LIDT/etc.), AMD-only 3DNow, etc. The ISA is not the hard part anyway. Dealing with the ABI (System V on Linux) to interface with C/C++ code, the kernel syscall interface, position independent code/executable (PIC/PIE) are somewhat bigger concerns and are going to apply to RISC as well.
secondcoming 4y ago
> Or is there an assembly that get rid of this gibberish tradition? C
- t-3 4y ago
  C is not all that close to the machine. It mostly works in an analogous way, but there have been plenty of times I've been frustrated by having to write a lot of complex, hard-to-reason-about C when the equivalent assembly is like 4-5 instructions. Types especially introduce a bunch of extraneous garbage that isn't at all related to what the machine does or what the program is trying to accomplish. Then, if you look at the generated code, it's ugly and not easy to follow at all, filled with unnecessary stuff.
- pjmlp 4y ago
  Actually I don't recal the name any longer, but TI used to have a DSP Assembler that was pretty simplified C, something like for the expressions dest = src1 op src2; Only basic control flow, no structured loops and so forth
stephc_int13 4y ago
The Saturn assembly language (used on HP calculators, like the HP48) is not too difficult to read, compared to x86, Z80 or ARM. Here is a bit of code extracted from the Diamonds source code: \* This is executed each time you die (with some lives left) maSTART_OVER GOSUBL dsQUICK_DRAW draw the bricks quickly, not disolve maSET_FLAGS ST=0 6 you can't knock out diamonds yet. ST=0 7 you have no key GOSUBL hbDRAW_KEY make sure no key is showing LCHEX #00001 white brick GOSUBL srSTO15_C erase mode GOSUBL emDRAW_BRICK show erase brick LC(5) BONUS_TIME a good time... GOSUBL srSTO25_C bonus time GOSUBL dlDRAW_LIVES draw lives left GOSUBL srRCL6_C get level addr C=C-CON A,5 now pointing to X,Y and DIR D0=C in D0 (pointing to X) C=0 A C=DAT0 2 read X GOSUBL srSTO0_C X D0=D0+ 2 pointing to Y C=DAT0 2 read Y GOSUBL srSTO1_C Y D0=D0+ 2 pointing to DIR C=0 A C=DAT0 1 read Direction GOSUBL srSTO2_C store it GOSUB grGET_READY display the GET READY window
- vidarh 4y ago
  I can't say I like that, but I'll note my first compiler on the Amiga started out as a wrapper around pure assembly, and supported similar arithmetic constructs where the asm generated was trivially predictable. E.g. similar to your example, you could write: D0.w = 42 .. to assign the immediate value 42 to the lower 16 bits of the D0 register (equivalent to MOVE.W #42, D0 in M68k assembly). Or: D0 = D0 + 2 (or D0 += 2) .. just as in your example ("ADD.L #2, D0"). You could also combine the asm with accessing variables etc. E.g.: D0 = x + 2 .. would be ("MOVE.L x, D0; ADD.L #2, D0" if x was a heap variable or "MOVE.L someoffset(SP), D); ADD.L #2, D0" if on the stack. But you could also just insert the assembly directly into the code... I wish I still had the source (it was initially written in assembly, and the gradually converted to itself); it was "interesting" writing a compiler where you could reliably intersperse higher level code with assembly "safely"
  - Drakim 4y ago
    Ah issue is that some (most?) architectures can't do math without messing with registers such as an accumulator, carry flag, negative flag, etc. While it looks convenient, I'm not sure I'd feel very confident about what happens with the CPU state using higher level syntax like that (especially if you want something more than a trivial addition)
vidarh 4y ago
I don't think we'd lose much by going to "return" instead of "rts" or "ret", "move" instead of "mov" (M68k even uses "move"), and "jump" instead of "jmp". But it used to matter when machines had memory measured in kilobytes, and now it's convention, and those of us who are used to reading assembly tend to recognise most of the common ways of contracting words that tends to be relatively fixed even across CPU families and so it's unattractive to change it. Even more so because the influx of new users of assembly languages that use it more than very occasionally are few and far between. There has been some attempts. E.g. see [1] for an "assembler" that provides some higher level constructs where there's a simple mapping to underlying machine instructions, but that might go further than what you'd like. [1] https://en.wikipedia.org/wiki/High_Level_Assembly https://en.wikipedia.org/wiki/High_Level_Assembly
- drpixie 4y ago
  It's all convention. Personally, I'd like more arithmetic convention. Instead of: MYARRAY: DEFW 100 ADD R1,R5,R7 MVI R2,R1,MYARRAY how about: MYARRAY: WORD[100] R1 = R5+R7 MYARRAY[R2] = R1 Not much harder top parse, and much easier to read. I see a couple of minor issues: needs a tweak to differentiate between (say) ADD and ADC; and assembler generally is small change, we're not putting much effort into it.
  - vidarh 4y ago
    Well, this is the kind of thing HLA does (also see my other comment in this thread about a compiler I wrote), but in practice there's little demand - most of the people who write asm are used to the conventions, and few people who write asm write much of it.
  - eimrine 4y ago
    This is not much easier to read, this is just on much higher level. A processor does not have a conception of brackets. Infix notation blurs the real number of operations. Processor has registers and your code does not say what you are putting in EAX what in EBX etc.
    - 4y ago
delta_p_delta_x 4y ago
I feel it's primarily x86-64 assembly that's so ridiculously hard to read, not least owing to the dozens of extensions and two syntaxes (GNU/AT&T versus Intel syntax). Furthermore, it is a register-memory ISA, and has a flags register which is set as instructions are executed, both of which lead to a lot of implicit behaviour that isn't immediately obvious from reading a given listing of x86-64 assembly. In contrast, the entire MIPS32 specification fits on one sheet of paper[1], and MIPS was used in some very productive and entertaining applications—the Sony PS1, PS2, and PSP, for instance. ARM is similar, as is RISC-V (although the former has a flag register). I find these RISC assemblies in general more straightforward than x86-64. They are also register-register, load-store architectures that make memory accesses quite explicit. This doesn't mean x86-64 or CISCs in general are inferior or superior to RISCs. They are two different approaches to the same problem, and as AMD has shown, it is possible to achieve good efficiency on CPUs using CISC ISAs, too. [1]: https://inst.eecs.berkeley.edu/~cs61c/resources/MIPS_Green_Sheet.pdf https://inst.eecs.berkeley.edu/~cs61c/resources/MIPS_Green_S...
- Joker_vD 4y ago
  I feel it's mostly the problem of the first impression. My first encounter with assembly was x86 and so it didn't really bother me ("ah, so that's what it is, okay"), and other assemblies were felt to be basically the same, maybe marginally nicer, maybe marginally worse, but that's it. But I do imagine that if your first foray into assembly started with RISC-V, then looking at x86 would absolutely scare you. Then again, 6502 specs can probably fit on one sheet of paper too, just as MIPS32 did, and it too has been used in very productive and entertaining applications—and yet it's even more idiosyncratic than x86; I've seen considerably more examples of "an instruction that sets flags; anywhere from 1 to 10 instructions that don't set flags; conditional branch" pattern in 6502 code than in x86. I guess it's similar to learning functional vs. imperative programming language as your first intro to programming? P.S. AT&T syntax for x86 is a) backwards: "subl %eax, %ebx" vs "sub ebx, eax" for "ebx -= eax", ugh; b) pretends that numbers are weird functions: "subl -32(%ebx,%ecx,4), %eax" vs "sub eax, [ebx+ecx * 4-32]" for "eax -= MEMORY_AS_ARRAY_OF_INT32[ebx+ecx * 4-32]", what the hell, minus thirty two is most definitely not a function with three arguments; neither is it a three dimensional array if we pretend that parens stand for array indexing as they do in FORTRAN.
ajsnigrutin 4y ago
So, like cp, ls, mv, rm, dd, df, ps, cc, etc.?
abudabi123 4y ago
The use of store/recall for memory was eye opening for me in nostalgia posts on old Wang computers.

Why is assembly locked into an ocean of cryptic sequence of letters that no respectable dictionary will try to pretend to be a word? Or is there an assembly that get rid of this gibberish tradition?

okaleniuk 4y ago

I tried to make a readable assembly once: https://github.com/akalenuk/milasm https://github.com/akalenuk/milasm But apparently, this is not a win-win, but a lose-lose since this notation is hated by both assembly programmers and not assembly programmers :-D

psychoslave 4y ago
Interesting project, thanks for sharing. That seems to be a bit tangent to my remark though: this seems to be more about adding syntactic structures, embodied with miscellaneous brackets, and there are still some obfuscating abbreviations like "ldstr".
- okaleniuk 4y ago
  Ah yes, but the whole point of the project is to go away from this: ldstr "Hello!" call void [mscorlib]System.Console::Write (string) And come to that: ((write: "Hello!")) So `ldstr` does indeed feature in the example but only as a "before" picture. But you're right, it is about adding syntactic features to the existing language.

userbinator 4y ago

Because it's its own language. Or is there an assembly that get rid of this gibberish tradition? Look up Randall Hyde's HLA. The famous author of various Asm books thought he could make a better syntax, and... almost no one wanted it.

pclmulqdq 4y ago

Assemblers for DSPs go so far as having arithmetic operators like "+" and "=" in their vocabulary, as well as allowing things like hierarchical braces as syntactic sugar if you want them. But you are intended to write assembly for them, so making it almost C-like has a lot of benefits. The real answer is that nobody is supposed to write assembly, and the way the instructions are written is very easy to parse. The only core that doesn't have the "it's ancient and we didn't know better" excuse is RISC-V, IMO.

mattashii 4y ago

A terse notation is useful for grokking code, as the information is spread across less characters that need to be interpreted by the brain. If you expanded all names, that would add cognitive overhead for all users and reduce the useful information per character, and potentially reduce the information that can fit on a screen significantly. While I'll agree that "cryptic sequences" are a more steep learning slope, they allow for much faster understanding of larger blocks of data/assembly once the "cryptic sequences" themselves are understood.

keithalewis 4y ago
Same reason people use APL inspired languages.
psychoslave 4y ago
>A terse notation is useful for grokking code Terse doesn’t necessarily mean opaque. Even if sticking to three letter words was an absolute requirement, there are plenty of English words that would make a better jobs at conducting the idea without falling into a collection of unpronounceable idiosyncratic terms. > as the information is spread across less characters that need to be interpreted by the brain. That’s not how the brain interpret text generally, once reading is fully acquired. Words, or even group of words are taken all together. Would it be for scriptural compactness alone, it would be far more efficient to use dedicated symbols optimized for that purpose. But if the idea is to optimize readability for an unknown large audience, then this is most likely a rather misguided choice. >If you expanded all names, that would add cognitive overhead for all users Well, I disagree. To my mind it would on the contrary significantly reduce cognitive load for those not already familiar with the uselessly abstruse terms, and add nothing to those already accustomed to code constructions in the machine specific language. >reduce the useful information per character Once again, this is a very poor metric for human interpretation of textual works. > potentially reduce the information that can fit on a screen significantly. So what? Number of signs displayed on the screen is certainly not the limiting factor here. How much juxtaposed signs a human attention can meaningfully handle is far more compelling. >they allow for much faster understanding of larger blocks of data/assembly once the "cryptic sequences" themselves are understood. I am not aware of any study that supports such a statement on empirical evidences. Maybe you can point me to such a study and help me change my mind? Assembly, back in the time of punched cards, had some reasonable rationals for avoiding input sequences longer than strictly necessary. Bu these rational no longer fit the contemporary digital landscape.

dj_mc_merlin 4y ago

You can just write your own assembler if you wish to. It's much easier than writing a full fledged compiler for a higher language, but that obviously doesn't make it easy. Otherwise, mnemonics are the way they are because of history, but also practicality. Since you're going to be writing them a lot, you want them to be short. It also doesn't take too long until their meanings are burned into your brain.

deleted 4y ago
[deleted]

chongli 4y ago

There are multiple real-world instruction sets that have a few dozen opcodes at most. Learning the mnemonics and operands for one of these ISAs can be done in an afternoon. Much easier than learning a really complicated language like C++ or Rust. The hard part about assembly language is its very limited abstraction. You’re only one step away from the metal. So it takes a lot of work to build a large program and it can be very tricky to get right because you don’t have a compiler or any types to help you. If you know what you’re doing, though, you can write some very small binaries!

osobo 4y ago
> You’re only one step away from the metal. You can write about assembly like a poet, at least.
- deleted 4y ago
  [deleted]
drpixie 4y ago
Very true, though there are some instruction sets with literally thousands - like the Intel x86-64. Give me RISC any day.
- mhh__ 4y ago
  RISC is probably hard to do for a big desktop chip. AArch64 is more like regular than reduced instruction set computing. Its a very big complicated ISA but also not a complete mess like X86. RISC-V is reduced by these standards but requires a very real instruction count penalty. The compressed ISA performs it's job admirably, do keep in mind, but I think it remains to be seen if some of the aggressively simple/clean aspects of risc-v end up hurting it.
- deckard1 4y ago
  x86 doesn't have thousands. That's overstating it by quite a bit. The assembler I wrote contains 1095 encodings. It's from ~2004 but 100% complete at the time, so sure new instructions have been added since. But those are encodings. SAL has like 8 encodings, SAR has 12, CMP has 14, etc. These encodings are just different ways to use the same opcode but with different source/target parameters (8/16/32-bit immediates or registers, etc.) Someone wrote a script that disassembled all the binaries on their Linux machine and counted the number of actual instructions used (mostly by gcc, of course). Only a tiny fraction of the total instructions were used: http://0x80.pl/notesen/2014-01-01-instruction-utilization.html http://0x80.pl/notesen/2014-01-01-instruction-utilization.ht... Just take the top 30 of that chart and learn those. The x86 contains a lot of instructions that no one needs to worry about. Things related to the ancient segment mode or x87 floating point, OS-privileged instructions (context switching, HLT/LIDT/etc.), AMD-only 3DNow, etc. The ISA is not the hard part anyway. Dealing with the ABI (System V on Linux) to interface with C/C++ code, the kernel syscall interface, position independent code/executable (PIC/PIE) are somewhat bigger concerns and are going to apply to RISC as well.

secondcoming 4y ago

> Or is there an assembly that get rid of this gibberish tradition? C

t-3 4y ago
C is not all that close to the machine. It mostly works in an analogous way, but there have been plenty of times I've been frustrated by having to write a lot of complex, hard-to-reason-about C when the equivalent assembly is like 4-5 instructions. Types especially introduce a bunch of extraneous garbage that isn't at all related to what the machine does or what the program is trying to accomplish. Then, if you look at the generated code, it's ugly and not easy to follow at all, filled with unnecessary stuff.
pjmlp 4y ago
Actually I don't recal the name any longer, but TI used to have a DSP Assembler that was pretty simplified C, something like for the expressions dest = src1 op src2; Only basic control flow, no structured loops and so forth

stephc_int13 4y ago

The Saturn assembly language (used on HP calculators, like the HP48) is not too difficult to read, compared to x86, Z80 or ARM. Here is a bit of code extracted from the Diamonds source code: \* This is executed each time you die (with some lives left) maSTART_OVER GOSUBL dsQUICK_DRAW draw the bricks quickly, not disolve maSET_FLAGS ST=0 6 you can't knock out diamonds yet. ST=0 7 you have no key GOSUBL hbDRAW_KEY make sure no key is showing LCHEX #00001 white brick GOSUBL srSTO15_C erase mode GOSUBL emDRAW_BRICK show erase brick LC(5) BONUS_TIME a good time... GOSUBL srSTO25_C bonus time GOSUBL dlDRAW_LIVES draw lives left GOSUBL srRCL6_C get level addr C=C-CON A,5 now pointing to X,Y and DIR D0=C in D0 (pointing to X) C=0 A C=DAT0 2 read X GOSUBL srSTO0_C X D0=D0+ 2 pointing to Y C=DAT0 2 read Y GOSUBL srSTO1_C Y D0=D0+ 2 pointing to DIR C=0 A C=DAT0 1 read Direction GOSUBL srSTO2_C store it GOSUB grGET_READY display the GET READY window

vidarh 4y ago
I can't say I like that, but I'll note my first compiler on the Amiga started out as a wrapper around pure assembly, and supported similar arithmetic constructs where the asm generated was trivially predictable. E.g. similar to your example, you could write: D0.w = 42 .. to assign the immediate value 42 to the lower 16 bits of the D0 register (equivalent to MOVE.W #42, D0 in M68k assembly). Or: D0 = D0 + 2 (or D0 += 2) .. just as in your example ("ADD.L #2, D0"). You could also combine the asm with accessing variables etc. E.g.: D0 = x + 2 .. would be ("MOVE.L x, D0; ADD.L #2, D0" if x was a heap variable or "MOVE.L someoffset(SP), D); ADD.L #2, D0" if on the stack. But you could also just insert the assembly directly into the code... I wish I still had the source (it was initially written in assembly, and the gradually converted to itself); it was "interesting" writing a compiler where you could reliably intersperse higher level code with assembly "safely"
- Drakim 4y ago
  Ah issue is that some (most?) architectures can't do math without messing with registers such as an accumulator, carry flag, negative flag, etc. While it looks convenient, I'm not sure I'd feel very confident about what happens with the CPU state using higher level syntax like that (especially if you want something more than a trivial addition)

vidarh 4y ago

I don't think we'd lose much by going to "return" instead of "rts" or "ret", "move" instead of "mov" (M68k even uses "move"), and "jump" instead of "jmp". But it used to matter when machines had memory measured in kilobytes, and now it's convention, and those of us who are used to reading assembly tend to recognise most of the common ways of contracting words that tends to be relatively fixed even across CPU families and so it's unattractive to change it. Even more so because the influx of new users of assembly languages that use it more than very occasionally are few and far between. There has been some attempts. E.g. see [1] for an "assembler" that provides some higher level constructs where there's a simple mapping to underlying machine instructions, but that might go further than what you'd like. [1] https://en.wikipedia.org/wiki/High_Level_Assembly https://en.wikipedia.org/wiki/High_Level_Assembly

drpixie 4y ago
It's all convention. Personally, I'd like more arithmetic convention. Instead of: MYARRAY: DEFW 100 ADD R1,R5,R7 MVI R2,R1,MYARRAY how about: MYARRAY: WORD[100] R1 = R5+R7 MYARRAY[R2] = R1 Not much harder top parse, and much easier to read. I see a couple of minor issues: needs a tweak to differentiate between (say) ADD and ADC; and assembler generally is small change, we're not putting much effort into it.
- vidarh 4y ago
  Well, this is the kind of thing HLA does (also see my other comment in this thread about a compiler I wrote), but in practice there's little demand - most of the people who write asm are used to the conventions, and few people who write asm write much of it.
- eimrine 4y ago
  This is not much easier to read, this is just on much higher level. A processor does not have a conception of brackets. Infix notation blurs the real number of operations. Processor has registers and your code does not say what you are putting in EAX what in EBX etc.
  - 4y ago

delta_p_delta_x 4y ago

I feel it's primarily x86-64 assembly that's so ridiculously hard to read, not least owing to the dozens of extensions and two syntaxes (GNU/AT&T versus Intel syntax). Furthermore, it is a register-memory ISA, and has a flags register which is set as instructions are executed, both of which lead to a lot of implicit behaviour that isn't immediately obvious from reading a given listing of x86-64 assembly. In contrast, the entire MIPS32 specification fits on one sheet of paper[1], and MIPS was used in some very productive and entertaining applications—the Sony PS1, PS2, and PSP, for instance. ARM is similar, as is RISC-V (although the former has a flag register). I find these RISC assemblies in general more straightforward than x86-64. They are also register-register, load-store architectures that make memory accesses quite explicit. This doesn't mean x86-64 or CISCs in general are inferior or superior to RISCs. They are two different approaches to the same problem, and as AMD has shown, it is possible to achieve good efficiency on CPUs using CISC ISAs, too. [1]: https://inst.eecs.berkeley.edu/~cs61c/resources/MIPS_Green_Sheet.pdf https://inst.eecs.berkeley.edu/~cs61c/resources/MIPS_Green_S...

Joker_vD 4y ago
I feel it's mostly the problem of the first impression. My first encounter with assembly was x86 and so it didn't really bother me ("ah, so that's what it is, okay"), and other assemblies were felt to be basically the same, maybe marginally nicer, maybe marginally worse, but that's it. But I do imagine that if your first foray into assembly started with RISC-V, then looking at x86 would absolutely scare you. Then again, 6502 specs can probably fit on one sheet of paper too, just as MIPS32 did, and it too has been used in very productive and entertaining applications—and yet it's even more idiosyncratic than x86; I've seen considerably more examples of "an instruction that sets flags; anywhere from 1 to 10 instructions that don't set flags; conditional branch" pattern in 6502 code than in x86. I guess it's similar to learning functional vs. imperative programming language as your first intro to programming? P.S. AT&T syntax for x86 is a) backwards: "subl %eax, %ebx" vs "sub ebx, eax" for "ebx -= eax", ugh; b) pretends that numbers are weird functions: "subl -32(%ebx,%ecx,4), %eax" vs "sub eax, [ebx+ecx * 4-32]" for "eax -= MEMORY_AS_ARRAY_OF_INT32[ebx+ecx * 4-32]", what the hell, minus thirty two is most definitely not a function with three arguments; neither is it a three dimensional array if we pretend that parens stand for array indexing as they do in FORTRAN.

ajsnigrutin 4y ago

So, like cp, ls, mv, rm, dd, df, ps, cc, etc.?

abudabi123 4y ago

The use of store/recall for memory was eye opening for me in nostalgia posts on old Wang computers.