Actually, I'm doing a home course to brush-up on my assembly chops. I remember now why I didn't like it the first time around in college.
Some assembly languages are harder than others. The best one I've ever used is PDP-11 -- very clean, very orthogonal, simple instruction coding that allows you to read an octal dump and immediately recognize and decode common instructions. C was originally designed to produce excellent PDP-11 code, and you see the PDP-11's influence on C, in particular stacks growing towards low memory (most C compilers evaluate their arguments in right-to-left order) and the auto-increment and auto-decrement expressions. A C statement like "*s++ = *t++;" translates into one single-word PDP-11 instruction.
ARM started out as a RISC machine (Acorn RISC Machine) and after a few versions became Advanced RISC Machine and later just ARM. ARMv7 is quite hard to understand: each version added new instructions by sticking them into gaps in the previous versions' instruction codings. If you like complex railroad time schedules with myriad footnotes, take a look at the quick reference cards at arm.com. Then for even more fun, download the entire ARMv7-AR Architecture Reference Manual (the "ARM ARM") and try to figure out how many instruction formats there are. This doesn't impact performance, since the chip-level hardware doesn't care if instruction fields are scattered all over the place, but not a good first ASM IMO.
x86 isn't much better. Again, not a good first ASM. And I've heard that PIC is pretty nasty.
PowerPC is quite regular and I recommend it. I've looked a little at the MSP430 and so far it looks like a PDP-11 combined with some RISC philosophy, so I'd definitely consider it. AVR isn't bad.
Since most people program in C, the complexities of the underlying ASM don't matter to most programmers. But those of us who write compilers and (dis)assemblers do see it and cringe and/or gag, depending on the ASM. Go write an assembler and/or disassembler for ARMv7-A, with both ARM and Thumb-2 codings. It's loads of fun! It's nothing like an 8080 assembler, believe me.
I think EEs should learn an assembler language that runs on processors they are most likely to encounter when they get out into the work force, not for processors that are simple enough to be hand-assembled. Nobody ever does that these days. And I doubt many EEs are ever going to need to write an assembler or compiler.
I have about 20 languages listed on my resume (as a CS guy), including assembler for several different processor families, but if I was a new EE grad right now, having C and ARM+Thumb assembler would open the most doors.
I really can't understand the obsession with teaching Electronic/Electrical Engineers assembler and C as a first language - or is the general interpretation of EE "Embedded Engineer" ?
Perhaps we should all use ADA more to encourage precision !
Electronic/Electrical Engineers should be studying hardware first so they should have a first programming language that assists that - I vote for Python but Matlab is technically OK but has other issues (see rant above).
I really can't understand the obsession with teaching Electronic/Electrical Engineers assembler and C as a first language - or is the general interpretation of EE "Embedded Engineer" ?
Perhaps we should all use ADA more to encourage precision !
Electronic/Electrical Engineers should be studying hardware first so they should have a first programming language that assists that - I vote for Python but Matlab is technically OK but has other issues (see rant above).
Top Comments