[pups] Swap device in V6?

[Warren Toomey]

In article by 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
> 
> 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?

That comment made me go through and scan my old AUUGNs for some articles
written by Dave Horsfall [who is on this mailing list]. I found his
article on porting V6 to the 11/23, but not for a port to the 11/34.

However, at least two tar files in the UNIX Archive have an m34.s in them:

Applications/Shoppa_Tapes/usenix_80_delaware.gz:
	delaware/maryland/os40/m34.s

Applications/Shoppa_Tapes/usenix_80_delaware.gz:m34.s:
	toronto/case/sys/conf/m34.s

The first appears to be modifications to V6, I haven't checked the latter
yet. It may be something worth pursuing.

	Warren

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