Re: wikipedia article

[Marcus Watts]

Various wrote:
> From: Otto Moerbeek <[EMAIL PROTECTED]>
> To: Ted Mittelstaedt <[EMAIL PROTECTED]>
...
> > What was the bit size of the CPU's originally used to write UNIX in Bell
> > Labs?
> 
> What's more, iirc the MMU of the pdp11 isn't what we call a MMU today,
> it could not even do paging.

The pdp-11 mmu could handle program relocation, segmentation (after
a fashion) and memory protection.  I'm not sure what more you
could expect from an mmu.  What you mean by "paging" is
probably "demand paging", which means the ability to run a program
without requiring that it be entirely resident.  The key
feature you need for that is a guarantee that any instruction fault
caused by missing memory can be either restarted or continued.
In most architectures that's a question of cpu design not mmu.

In the case of the pdp-11 that's mostly a moot point.  The pdp-11 only
provides for mapping the 64k of memory space into into 8 segments
(addressable on 64-byte "clicks") and there's just not much win to
demand paging 8 "pages".  (actually 6 x 8 pages; there was kernel,
user, and supervisor mode, & each had separate instruction and data
spaces, but supervisor mode was rarely used in Unix environments, and
only a few large user mode programs ran using split I/D space.)  For
what it's worth, though, I *think* it was possible to restart most
instructions on the /45 and /70, which were the "big" machines and the
primary target of most later pdp-11 work.  In fact, some use was made
of this feature -- automatic stack growth.  If you look through ancient
Unix source, you'll find interesting bits of kernel code that manage
this.

There's actually a cheesy way to do demand paging with microprocessors
that don't support demand paging (such as the original 68000--another
"16 bit" machine).  The way to do this is to run two processors in parallel
but skewed by one instruction.  If the first one does a bad memory fetch,
then the second one will not have fetched the instruction causing the
fault so contains restartable machine state.  Masscomp sold a machine
like this once.

-Marcus Watts
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: wikipedia article

[Marcus Watts]

Various wrote:
> Message-ID: <[EMAIL PROTECTED]>
> Date: Wed, 14 Jun 2006 00:50:53 +0200
> From: Johnny Billquist <[EMAIL PROTECTED]>
> Organization: Update Computer Club
> User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923)
> X-Accept-Language: en-us, en
> MIME-Version: 1.0
> To: =?ISO-8859-1?Q?Per_Fogelstr=F6m?= <[EMAIL PROTECTED]>
> CC: [EMAIL PROTECTED], Marcus Watts <[EMAIL PROTECTED]>,
> Otto Moerbeek <[EMAIL PROTECTED]>,
> Ted Mittelstaedt <[EMAIL PROTECTED]>,
> John Nemeth <[EMAIL PROTECTED]>,
> Nikolas Britton <[EMAIL PROTECTED]>,
> Ted Unangst <[EMAIL PROTECTED]>,
> =?ISO-8859-1?Q?H=E1morszky_Bal=E1zs?= <[EMAIL PROTECTED]>,
> misc@openbsd.org, freebsd-questions@freebsd.org,
> [EMAIL PROTECTED]
> Subject: Re: wikipedia article
> 
> Per Fogelstr=F6m wrote:
> > On Tuesday 13 June 2006 14:23, Rick Kelly wrote:
> >=20
> >>Johnny Billquist said:
> >>
> >>>>There's actually a cheesy way to do demand paging with microprocessor=
> s
> >>>>that don't support demand paging (such as the original 68000--another
> >>>>"16 bit" machine).  The way to do this is to run two processors in
> >>>>parallel but skewed by one instruction.  If the first one does a bad
> >>>>memory fetch, then the second one will not have fetched the instructi=
> on
> >>>>causing the fault so contains restartable machine state.  Masscomp so=
> ld
> >>>>a machine like this once.
> >>>
> >>>Didn't the first Apollos do this?
> >>
> >>And also the Sun 1.
> >=20
> >=20
> > IIRC it was simpler than that. When the first cpu caused a 'miss' it wa=
> s put
> > in wait and cpu 2 handled the pagein and then released cpu 1. Keeping t=
> he two
> > cpus synched, one instruction apart would have been too complicated if =
> not
> > impossible...
> 
> Your idea will not work, as far as I can tell.
> If the first CPU instruction execution causes a miss, the end result in=20
> the CPU will be pretty undefined, and you cannot restart. That's the=20
> whole point in why you'd have a second CPU shadowing the first one. So=20
> that you'd be able to restore the state as it were before the illegal=20
> memory access.
> And that was the problem with the original 68000. On an illegal memory=20
> reference, you would not know what state the CPU was in before the=20
> instruction, so you could not back it up, and re-execute the instruction=20
> after a page fault.
> 
>   Johnny

Several clarifications.  The sun-1 did not have a dual CPU page fault
arrangement.  It used a slightly higher clock speed version of the
same CPU board used previously used by codata & 4 other vendors,
originally designed by stanford university.  Instead of using the
motorola MMU which was late to market, expensive, & slow, or industry
standard MMU cache logic ("TLB"), they used a very clever generic chip
implementation that used the CPU alternate space instructions to manage
dedicated high speed RAM which provided all the mapping.  This managed
a page addressed space, but did NOT do demand paging.  Another exciting
low-cost feature of the sun-1 CPU was "software" dynamic ram refresh-
every 2 ms, the CPU was interrupted by the refresh interrupt and would
execute 127 nop instructions.  The sun-2 was very similiar to the sun-1,
but upgraded the 68000 to a 68010 (which could do instruction restarts
and hence demand paging), deleted the onboard RAM, and instead added
the ability to use DMA via an IOMMU to private bus RAM.  The sun-1 ran
unisoft version 7 unix, complete with swapping.  The sun-2 ran "4.2bsd".
I've got an actual physical "codata" processor manual (complete with
schematics) but I believe I've seen a sun-1 processor manual in pdf
somewhere on the web recently.

I'm not 100% sure how masscomp or apollo handled page faults.  The
impression I had is that the first CPU got "reset", and the second was
interrupted on the instruction boundary and saved its CPU state first
thing in the interrupt handler.  While the user register state in the first is
"undefined", the CPU itself is still good - it can take an interrupt,
transition into kernel mode and recover machine state from somewhere
else (like the 2nd CPU) just fine.  That seems to me to be the most
sane way it could have been handled.  I suppose it's possible the 2nd
CPU could have been instead paused, while the first CPU processed the
segmentation violation, trashed its non-recoverable machine state,
handled the exception, and ?somehow? relo