Not to fan the flames but I have experience and opinions on the subject: Glenn Roberts via vcf-midatlantic writes:

I hate to be the bearer of bad news but assembly language is probably the most tedious of programming environments.

VAXman:

That's not necessarily true. It depends upon the machine (CPU) and its language (instructions, address modes, registers, conventions, etc.).

Part of me wants to agree, having assembler programmed 8, 16, 32 bit machines. There's a deep satisfaction to optimizing a program with "green card" in hand (IBM 360 reference card - lists all instructions). But even I must concede that assembler programming the Z80 was dogmeat after having programmed IBM 360/370. Too few registers, weak instructions and other things that make assembler programmers happy. Even now, when considering microcontrollers, I look over the instruction set as some measure of goodness: is the architecture clean? Are the instructions flexible enough to do as much as possible in one cycle? But assembler programming is just the tip of the iceberg. There are programming "traditions" and conventions, particularly register usage, if you're to link to any libraries or supervisor calls. Assembler programmers depend a lot of macros and libraries to make their programming environment more pleasant. The joy of the IBM 1130 was seeing your program running on the front panel and understanding what it was doing on the lowest possible level! Lotsa libraries and shareware, even in the 70s. But that's all for CISC CPUs. RISC sapped out all the pleasure with too many details for humans to track: pipelining, delayed branch, instruction hazards, cache, etc. Concurrent Computer Corp converted from 360-like microcoded CPUs to the MIPS R3000. The internal courses were wonderful, covering all the aspects why RISC is the way to go, and all the trade-offs, particularly the need to rely on the compiler for optimization and bug fixes/workarounds.

Good assembly language programmers have libraries of frequently needed routines (e.g. to print text or do = 16 bit manipulations).

It helps a lot. The 68000 trainer I used for a lab course had a few functions in the ROM such as print character, print string. It sure accelerated my progress. But if there were no ROM, a simple workaround would've been to cut-and-paste just the functions I needed into the source file. Or learn the link-editor to link the main to libraries.

I/O routines, unless one is writing the I/O subsystem and device drivers, should be part of the OS or, in lesser systems, ROM, Bios, etc. Inventing the wheel everytime you want to roll is not very productive.

Agreed. That's part of why 70s Development Boards were really USEFUL once ROMS/EPROMS were large enough to have some support. CP/M started the portable "BIOS" concept: a minimal set of foundation subroutines upon which everything else is built. I still marvel at how much functionality Woz squeezed into the Apple 1 with those TEENY ROMS (256 bytes?) -- jeff jonas