4 ms·

Books, magazines (BYTE, Nibble[0], Dave Ciarcia's Circuit Cellar), computer camps, BBS. But because there were so few resources, they tended to be FAR higher qu

Books, magazines (BYTE, Nibble[0], Dave Ciarcia's Circuit Cellar), computer camps, BBS. But because there were so few resources, they tended to be FAR higher quality than googling or Stack Overflow. Plus things weren't as complex back then: you could memorize the 6502 instruction map in an afternoon. The only way I really learned was by saving my money (returning soda cans and mowing lawns) and buying MULTIPLE books on the same subject because the examples or explanations differed enough to triangulate WTF was going on. Nibble magazine had source code in it every month for the Apple that explained how stuff worked. I once typed in 14 pages of assembly to write a space-invader's game. Most of it was bitmaps. When I was 13 I won a scholarship to a computer camp and spent a month with experts who answered every question I had and taught me how to debug. It expanded my knowledge 1e6%. I'm a late-70's kid. I grew up near Yale University I bought programming books from the Yale Co-op book store with allowance money. I started with BASIC on a relative's C64, then got into 6502 assembly[1] on the school Apple computers[2], then bought a book on 286 protected mode when I got to highschool. Then I worked for a machinist who taught me C in the mid-80's. It was really hard without a network of experts to reach out to. I still a have the latter two books, below, with my big, goofy-kid handwriting in them: [0] Nibble mag ... https://www.nibblemagazine.com/ https://www.nibblemagazine.com/ [1] 6502 Software Gourmet Guide & Cookbook, Robert Findly ... https://www.amazon.com/6502-software-gourmet-guide-cookbook/dp/B0006EAKSM https://www.amazon.com/6502-software-gourmet-guide-cookbook/... [2] Beneath Apple DOS, by Don Worth and Pieter Lechner ... https://www.amazon.com/Beneath-Apple-DOS-Don-Worth/dp/0912985003/ref=sr_1_1?dchild=1&keywords=Beneath+Apple+DOS%2C+by+Don+Worth+and+Pieter+Lechner&qid=1590876003&s=books&sr=1-1 https://www.amazon.com/Beneath-Apple-DOS-Don-Worth/dp/091298...

shivekkhurana 6y ago
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.
- 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!

shivekkhurana 6y ago

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.
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!