For a long time I considered myself a "world class" x86 assembly language programmer when it came to squeezing the crap out of code to make it as tiny as possible (a talent too often ignored these days). Others try to make things fast, I mostly focused on making them small because the vast majority of code isn't terribly speed sensitive. The bulk of code in a program or operating system usually handles oddball cases, error paths, CPU errata, etc and isn't executed all that often, yet it MUST BE THERE for the code to be "correct". The smaller that necessary baggage is, the more memory is left over for running the code that does the useful things.
It has been a few years since I did any assembler programming though. Did I still remember all the dirty tricks, arcane minutia, and nasty swindles that are the stock and trade of a premier code tweaker looking for every last byte? I really wasn't sure.
So I've got this little program (actually its an API test suite) I've been evolving ever since the early 90's. Its a modest bit of assembler code, on the order of 12,000 lines with several thousand lines of C code thrown in as well.
Today I got "in the zone" for a few hours and whipped out about 400 lines of insanely compact assembler code. About 50 new functions and the new module weighed in just under 500 bytes. I just made the minor mods to integrate the new stuff into the project and the size of the whole dropped by a few kilobytes. Add 500 bytes of magic, and the whole goes down by 6X what was added. This is the way programs should evolve!
Yes, I still have "the touch", and the 400 lines of new assembler code functioned perfectly through 4,000+ testcase variations that use it very heavily.
3 comments:
I'm going to be taking a class on assembly language this spring, barring it getting canceled by the school like my last attempt at taking a class post-graduation. I have never had a chance to do assembly before, though I've seen it enough to not be scared of it.
If you're anywhere near an Intel field office, stop by someday. They should have some manuals on the x86 instruction set and they'll probably be free.
There's all sort of books and online tutorials on assembler, which are good starting points.
I would suggest studying the CPU architecture and instruction set first. There's all sorts of crud involved in most assemblers, segments, assume's etc that can be a distraction if you don't understand the architectural reasons for their existence first.
I'd grab an old copy of Borland's DOS based Turbo Debugger somewhere and play with that. TD is capable of assembling instructions and letting you play with them immediately without all the gorp a command line assembler entails.
x86 assembly is probably what they will use in the class. I'm not in a rush to learn ASM right now because there are almost no opportunities for me to learn it. I want to take it primarily as an introduction to computer engineering at George Washington University.
Post a Comment