Fair point I suppose. I don't dispute that you have to learn on something, but what I was trying to get across was the need for more relevant examples. There is a lot to learn in assembly level programming, and much of it is about addressability, registers and capabilities of the processor, and interaction with the operating system. Why add to this burden by making people learn stuff they are unlikely ever to use in the real world?
Take the example above - reading a number from the terminal, and outputting the roman equivalent. Messrs. Kernighan, Ritchie, and Torvalds have written whole operating systems almost entirely in C. Hands up who thinks you will ever need to do terminal I/O from assembly level code? If we substitute the simple number conversion for a complex and time critical calculation that must be performant, and using the code size and/or optimisation rationale above, you'd still do the terminal I/O from a high level program and call the assembler subroutine to reformat the number before display. So why learn terminal I/O in assembler?
Creating a subroutine to reformat the numbers would be far more useful as a teaching example - it teaches about program linkage, addressability, parameter passing, return variables, integer and modulus arithmetic, and possibly even data validation and table handling. These are all things you need to know, and are applicable to almost every program you write.
Steve
[small]"Every program can be reduced by one instruction, and every program has at least one bug. Therefore, any program can be reduced to one instruction which doesn't work."
(Object:
erlDesignPatterns)[/small]