[pups] Swap device in V6?

[John Holden]

> The good news is, this fixed my ps problem - ps now works.  The bad news
> is that cc still fails with the following error:
> 
> fFatal error in /lib/c0
> 
> The lowercase f appears, followed shortly by the rest of the line.  I've
> tried the -c option to suppress linking, and still get this error.  I
> don't get this error on the Supnik emulator.  

'/lib/c0' is the first pass of the C compiler, after the preprocessor
has be run (the order is cc, c0, c1, c2 for the optimiser, and then 'as'
to produce the object file). I dimly recall that the various passes forked
by 'cc' didn't bother to catch signals, so any error just gives the
"Fatal error in ..." message. The '-c' would have no effect this early.

You could try the '-f' option, that uses a different compiler (with FP
emulation).

Assuming that you don't have a corrupted binary, or faulty processor/memory,
then is one obscure possibility. While a user program will not see any
difference between a 11/34 and 11/40 (except for floating point instructions),
the behaviour after a memory management fault IS different. The non ID space
processors (11/23/34/35/40/60) don't have a register to record the changes
in the general cpu registers after a fault, and it has to be calculated in
software. The 34 and 40 leave the registers in different states after a fault.

The classic example is "cmp -(sp), -(sp)" to extend the stack. This may generate
a fault because the stack needs to grow dynamically. The kernel extends the
stack (where automatic variables are allocated), and then attempts to 
reexecute the instruction. In the case of a 34 using a standard m40.s,
it sometimes gets it wrong, and is very program and data dependent.

Does this ring any bells with people having ported unix to 11/34's?


Received: (from major at localhost)
	by minnie.cs.adfa.edu.au (8.9.3/8.9.3) id OAA71920
	for pups-liszt; Wed, 28 Feb 2001 14:58:47 +1100 (EST)
	(envelope-from owner-pups at minnie.cs.adfa.edu.au)