🚀 go-pugleaf

In article <6586@galbp.LBP.HARRIS.COM> jsb@advdev.UUCP (Jeff Barber) writes:
>No-one seems to have mentioned that there are some things in operating
>system-type software which can't be done without assembler.

>For example:
>1.	Power-up memory tests in boot ROM's
>2.	(hardware level) Input/output
>3.	For access to machine-specific registers and other features.

You don't need >>assembler<< for any of these.
For (1), all you need is a PROM burner and a hex keyboard.
*Machine*language* and *assembly*language* are not identical!

For (2) and (3) the same is of course true; all you have to be able to
do is generate the right sequence of bits and talk the loader into
accepting it as a subroutine.  For example, I have seen
	/* foo.c */
	short code_proc[] = {
	    0x~~~~, ..., 0x~~~~
	};
	/* bar.c */
	extern void code_proc();
	...
	    code_proc();
	...
{This is actually *more* portable than assembly code--there are several
 incompatible assemblers for M680x0s, but those constants worked on any
 68k.  Portable to any other architecture it wasn't.}

Then again, it depends on what you are willing to accept as assembly code.
For example, using BLISS on a DEC-10, there was *no* instruction you could
not generate, symbolically yet.  The same is true of PL/360 ("opsyn"
declarations).  These MOHLLs normally operated at about the semantic level
of BCPL.  (You *had* to generate specific instructions on the DEC-10,
because file I/O was handled via extracodes, with the channel number in
the accumulator field of the instruction!)