5 ms·

14 pages of assembly! Do you still work in the tech domain? Do you have any guidance, or words of wisdom, for people with less experience?

jlokier 6y ago
14 pages is pretty small for an assembly program. After all, to do anything useful it's often 10 times longer than doing the same thing in C, which is itself longer than doing the same thing in, say, Python.
- staycoolboy 6y ago
  You are probably thinking of assembly code generated by a compiler, not by a human. Human generated ASM is far more economical (e.g. have a look at Abrash's legendary "Black Book"). Or the Linux 1.0 kernel. It fits on small poster (can't seem to find it on google, a co-worker had it in his office in the mid-90's). Or shellcode, which is small asm by nature. Very very clever asm. More examples (About half my contract work is in the embedded space, so I encounter assembly on a weekly basis): highly-tuned algorithms, such FFTs on different DSP architectures from TI and Arm, or a very cool parallel FP64 dividing algorithm implemented in 8-bit integer assembly I saw recently; or for startup code (vector and interrupt table generation on init); or for extremely constrained systems like near-field powered products. For example, I worked on a NFC card reader that read SmartCards. The Smart Card code was hand-written assembly and only a few hundred bytes. So yea, compiled C will always be bigger than hand-written assembly, but you're missing the point with Python: Python takes gigabytes of libraries to be installed, and tens/hundreds of megs of code is loaded during runtime. So it is not a valid comparison. Just look at memory usage of the typical python program.
- jlokier 6y ago
  To the sibling [dead] comment: > You are probably thinking of assembly code generated by a compiler, not by a human An understandable response, but no as it happens I'm not. At various times I've been an expert-level assembly language programmer and have programmed at least 20 architectures. I forget, some are quite obscure, especially non-descript Qualcomm DSPs :-) At one time I won an informal competition to make the smallest ELF executable, and I used to write games engines, back when every cycle counted, and artfully hand-tuned, clever texture mapping techniques, tuned for each generation of processor, alongside higher-level mathematical algorithms to get the best out of the low-level loops were the sort of thing needed. So I'm familiar with Michael Abrash, and "human-optimised" dense assembly. I've written 100% assembly programs on the order of 10,000s of instructions long, which corresponds to 100s of "pages". I wouldn't do that these days without a good reason, in fact I'm into very high level architecture and optimisation methods, and designing languages around problems, but I do know my way around an assembler when needed. I've also reverse engineered a number of things from machine code back to C, sometimes to fix bugs in the machine code and create binary patches, sometimes to port it, and sometimes to reverse engineer how to operate a device. So I've read and analysed large amounts of assembler too, but to be fair that code does tend to be mostly compiler generated.
  - deleted 6y ago
    [deleted]
  - deleted 6y ago
    [deleted]
staycoolboy 6y ago
There's only one way to get experience: make things. Just get in there and code. You'll be frustrated a lot, but it's a learning experience. Pat yourself on the back when you hit an obstacle and work through it, don't worry if you don't finish your original goal; the goal is to learn. Ask any hacker on this site and the # of projects finished vs the # of projects half-done rapidly approaches zero!

jlokier 6y ago

14 pages is pretty small for an assembly program. After all, to do anything useful it's often 10 times longer than doing the same thing in C, which is itself longer than doing the same thing in, say, Python.

staycoolboy 6y ago
You are probably thinking of assembly code generated by a compiler, not by a human. Human generated ASM is far more economical (e.g. have a look at Abrash's legendary "Black Book"). Or the Linux 1.0 kernel. It fits on small poster (can't seem to find it on google, a co-worker had it in his office in the mid-90's). Or shellcode, which is small asm by nature. Very very clever asm. More examples (About half my contract work is in the embedded space, so I encounter assembly on a weekly basis): highly-tuned algorithms, such FFTs on different DSP architectures from TI and Arm, or a very cool parallel FP64 dividing algorithm implemented in 8-bit integer assembly I saw recently; or for startup code (vector and interrupt table generation on init); or for extremely constrained systems like near-field powered products. For example, I worked on a NFC card reader that read SmartCards. The Smart Card code was hand-written assembly and only a few hundred bytes. So yea, compiled C will always be bigger than hand-written assembly, but you're missing the point with Python: Python takes gigabytes of libraries to be installed, and tens/hundreds of megs of code is loaded during runtime. So it is not a valid comparison. Just look at memory usage of the typical python program.
jlokier 6y ago
To the sibling [dead] comment: > You are probably thinking of assembly code generated by a compiler, not by a human An understandable response, but no as it happens I'm not. At various times I've been an expert-level assembly language programmer and have programmed at least 20 architectures. I forget, some are quite obscure, especially non-descript Qualcomm DSPs :-) At one time I won an informal competition to make the smallest ELF executable, and I used to write games engines, back when every cycle counted, and artfully hand-tuned, clever texture mapping techniques, tuned for each generation of processor, alongside higher-level mathematical algorithms to get the best out of the low-level loops were the sort of thing needed. So I'm familiar with Michael Abrash, and "human-optimised" dense assembly. I've written 100% assembly programs on the order of 10,000s of instructions long, which corresponds to 100s of "pages". I wouldn't do that these days without a good reason, in fact I'm into very high level architecture and optimisation methods, and designing languages around problems, but I do know my way around an assembler when needed. I've also reverse engineered a number of things from machine code back to C, sometimes to fix bugs in the machine code and create binary patches, sometimes to port it, and sometimes to reverse engineer how to operate a device. So I've read and analysed large amounts of assembler too, but to be fair that code does tend to be mostly compiler generated.
- deleted 6y ago
  [deleted]
- deleted 6y ago
  [deleted]

staycoolboy 6y ago

There's only one way to get experience: make things. Just get in there and code. You'll be frustrated a lot, but it's a learning experience. Pat yourself on the back when you hit an obstacle and work through it, don't worry if you don't finish your original goal; the goal is to learn. Ask any hacker on this site and the # of projects finished vs the # of projects half-done rapidly approaches zero!