Re: wikipedia article

Various wrote:
Message-ID: <448F414D.7090302@xxxxxxxxxxxx>
Date: Wed, 14 Jun 2006 00:50:53 +0200
From: Johnny Billquist <bqt@xxxxxxxxxxxx>
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?= <pefo@xxxxxxxxxx>
CC: rmk@xxxxxxxxxxx, Marcus Watts <mdw@xxxxxxxxx>,
Otto Moerbeek <otto@xxxxxxxxx>,
Ted Mittelstaedt <tedm@xxxxxxxxxxxxxxxx>,
John Nemeth <jnemeth@xxxxxxxxxxxxxx>,
Nikolas Britton <nikolas.britton@xxxxxxxxx>,
Ted Unangst <ted.unangst@xxxxxxxxx>,
=?ISO-8859-1?Q?H=E1morszky_Bal=E1zs?= <balihb@xxxxxxx>,
misc@xxxxxxxxxxx, freebsd-questions@xxxxxxxxxxx,
netbsd-users@xxxxxxxxxx
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? reloaded machine state from the
2nd paused CPU. Switching to a different process while the 2nd CPU was
paused waiting for a page to come in off disk might have been a bit
awkward. So while I think this might have been made to work, I doubt
it could have performed as well.

So far as the "2 cpu synchronization logic" goes - either of these
would have required such a beast. The 68000 used "address spaces" to
distinguish between instruction and data references, so instruction
synchronization was no problem. It might have been necessary to decode
instructions to sort out operands & other instruction stream
references, including logic to sort out page faults in the middle of an
instruction fetch. Between instruction references there could have
been a variable # of data references - there would have had to be a
memory pipeline capable of caching the maximal number of data
references between instructions -- 6? 10? You'd also have to handle
memory writes. If I remember right, the 68000 always did all memory
writes at the end of an instruction, so it *probably* wasn't necessary
to buffer memory writes until after the instruction was complete. I
believe the logic to do all of this took up a fairly large board in
the masscomp and was *way* more complicated than the entire sun-1 MMU
design. As I think on this, I don't think the 2nd CPU needs to be
exactly one instruction behind -- it just has to be at *least* one
instruction behind.

Now, if you think Masscomp is strange, wait until you learn about
Morrow System's Micronix. If I remember right, this was a Z80 on
an S100 board full of MMU logic, including logic to implement kernel
vs. user mode.

-Marcus Watts
_______________________________________________
freebsd-questions@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questions-unsubscribe@xxxxxxxxxxx"

Relevant Pages

  • Re: [PATCH] Mantaining turnstile aligned to 128 bytes in i386 CPUs
    ... :This doesn't contradict your claim since main memory is not really involved. ... that gives the same not-very-real-world cache state for all iterations ... full, and the cpu stalls anyway. ... static instruction order makes it easiest for them, ...
    (freebsd-arch)
  • Re: [PATCH] Mantaining turnstile aligned to 128 bytes in i386 CPUs
    ... :This doesn't contradict your claim since main memory is not really involved. ... that gives the same not-very-real-world cache state for all iterations ... full, and the cpu stalls anyway. ... static instruction order makes it easiest for them, ...
    (freebsd-current)
  • Re: PROFESSIONAL floating-point algorithms.
    ... forward by tight coupling of humor with instruction. ... >) Any CPU that has a slow random access memory for any reason could make ... >) point of failure such that RAM access is slow. ... instructions to refresh the memory which is "read mostly". ...
    (comp.programming)
  • Re: [PATCH] x86 - Enhance DEBUG_RODATA support - alternatives
    ... has been pulled out of the x86 tree. ... text_poke required to support this. ... correctly and so the CPU HOTPLUG special case can be removed. ... When you use this code to patch more than one byte of an instruction ...
    (Linux-Kernel)
  • Re: Simple function arguments
    ... are 2 names refering to the same memory location and use that. ... In the internals of a CPU there are various registers. ... address is stored from where the next instruction from memory is read and executed. ... what is generally referred to as 'The stack'. ...
    (comp.lang.cpp)