Path: utzoo!utgpu!watmath!clyde!att!pacbell!ames!sgi!arisia!quintus!ok
From: ok@quintus.uucp (Richard A. O'Keefe)
Newsgroups: comp.lang.misc
Subject: Re: Assembly or ....
Keywords: Assembly
Message-ID: <773@quintus.UUCP>
Date: 30 Nov 88 09:01:29 GMT
References: <1388@aucs.UUCP> <407@ubbpc.UUCP> <6586@galbp.LBP.HARRIS.COM>
Sender: news@quintus.UUCP
Reply-To: ok@quintus.UUCP (Richard A. O'Keefe)
Organization: Quintus Computer Systems, Inc.
Lines: 36

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!)