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