What is on Your Mind?

Hi. I learned C in high school and am proficient in it. At the college while learning microcontrollers there was a short course on assembly language which I skipped but had no trouble as most of the application programming had to be done in C. Should I go back n learn assembly language as I have heard it gives good insight into the hardware? Is it at of any (significant) use in embedded systems?

Embedded systems are often restricted and picky. There will definitely be things which can't be done in pure C, only assembler -- system-specific things and the like. (you can often do inline assembler in C to avoid having to make large sections of it, though).

Learning how to program them in assembler would help to explain what the system limits mean to C.

The real advantage to learning assembly language is a low-level understanding of pointers and memory handling. You'll have a better understanding of the real operation and cost versus someone who has not. I really enjoyed my foray into assembler and still revisit it on occasion. A simple internet search of 'assembler emulator linux tutorial' will provide of wealth of suggestions for your iteration over a set of integers... The world is filled with average developers; it pays to stretch yourself.

got it. need to grab my gear n fall in

I started my career back in the late seventies and on IBM mainframes there was either COBOL or assembler - with the 2.5 KB real memory my first system (already outdated at that time) had the choice was quite clear: learn assembler and every dirty trick there was to save some bits here, some cycles there ....

Later, in the eighties, i wrote software for DSPs and embedded systems, mainly the DSPs of Analog Devices and the Motorola 56k-series. Again, it was assembler to the fullest extent: when you write the internal software for a telephone switchboard and the company wants to sell a few millions the only thing that counts is: how many cycles did you use for that task? The lower cycles, the lower the clock rates could be, which means you can buy lower graded CPUs, which cost exponentially less which means a BIG difference in customer price. If you could save one arithmetic unit or one register, the custom-built processors could be built without these parts which made them cheaper too.

We used to beat optimizing compilers by a very large margin. OK, we couldn't decipher our own code three months after "tape-out" (the tasks got simulated on an ICE and finally the tape with the processor specification was sent to the provider of the DSPs to be built on order), but it was expected to write the next version from scratch anyway.

One of my first jobs on a PC was to write a DOS device driver for a specialized file system for the real-time storage of acoustic data. This was the time of MFM-disks and the data rate for a usual 16-bit sampling in stereo frequency (44.1 kHz) is just a tad below the bandwidth of the ST-506 interface. My driver had to use every ounce of bandwidth it could get just keep up. Mind you, we had one of the brand-new hot 16 MHz NEAT 286, an extremely fast system!

Sure, these are extremes. But ones uses assembly language for the same reason we used to use assembly throughout computing history: for its unparalleled speed and for the sheer control it gives you over the system and its hardware. C is a language nicely suited for rapid prototyping, but i'm still quite confident to be able to beat any C-compiler in terms of speed of execution with hand-crafted assembler code. Even with all those nifty optimizations switched on.

This is nothing to say against C - in fact i like C. But to really understand what C is about you have to have experienced the problems solved/avoided by its use. You have to have been at the very bottom at least once to appreciate being on top. And, who knows, you might even start to like being at the source of things.

bakunin

invaluable...