Unix and C

[Martin Weitzel]

In article <1990Nov8.152413.10792 at ux1.cso.uiuc.edu: mcdonald at aries.scs.uiuc.edu (Doug McDonald) writes:
:In article <1990Nov8.100816.6004 at ericsson.se> epames at eos.ericsson.se writes:
:>>
:>Of course the whole of Unix cannot be written in C but only a small
:>percentage need be written in assembler. 
:
:It is true that an OS cannot be written entirely 100% in conformant 
:ANSI C in general. However, for some processors it probably CAN
:be written in an UNHOSTED ANSI C with the only "extension" being that
:you can be sure that you know exactly what constructs like
:
:*((volatile unsigned char *)12345) = 6789; 
:
:will in fact do (down to the coding level, such as how the mov instruction
:would be used. Perhaps a couple of pragmas would help.
:
:Some PDP-11 processors are probably in this class. I can think of only one
:obvious problem - many have a Processor Status register that requires
:special instructions to access.
:
:Processors that have special IO instructions of course exist - there
:indeed C alone cannot an operating system create.

Given that C-Compilers are allowed (though, of course, not required!)
to give `undefined behaviour' some implementation defined meaning,
you can even go some step further: An implementation that defines the
mapping functions between data adresses and function pointers in a
resonable way, and with a machine, that allows to execute instructions
from the data space, you can put bytes of machine instructions in a
statically initialized array% and so "execute" arbitrary op-codes,
like the following example shows:

	/* WARNING: HIGLY UNPORTABLE CODE AHEAD */

	static char machprog[] = { ... , ... , ... };
	                          ^^^^^^^^^^^^^^^^^   specify machine
	                                              instructions here

	(*(void (*)()) &machprog)();                  and 'jump subroutine'
	                                              to them here

Of course, this technique is only recommendable in certain special
cases. A cleaner approach were a separate module in assembly language.
Nevertheless, one part of the `C-Philosophy' allways was and still is:

    Don't prevent the programmer from doing what needs to be done!

%: The example shows an array of char here; depending on the machine
   an int or long array could be more appropriate.
-- 
Martin Weitzel, email: martin at mwtech.UUCP, voice: 49-(0)6151-6 56 83