30 Oct
2010
30 Oct
'10
6:51 a.m.
On 2010-10-30 01:12, Ethan Dicks<ethan.dicks at gmail.com> wrote:
They are two different things, yes. But they serve the same purpose.
It's just different ways of dealing with what to do after a page fault
(or any trap from which you want to recover).
The advantage of instruction continuation, especially with the 68010, is
that it didn't introduce any incompatibilities with the 68000. If you
had implemented instruction restarts instead, you would have had to
introduce a bunch of new registers in the CPU that kept track of partial
modifications done before the trap, so that you could undo them before
restarting the instruction. With instruction continuation, it's all
preserved internally in the CPU without exposing the software to
anything new.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
On Fri, Oct 29, 2010 at 2:26 PM, Brent
Hilpert<hilpert at cs.ubc.ca> wrote:
Yes, the 68010 worked fine with demand paging. The 68000 did not.
Neither of them implemented instructions restarts, though. As noted
below, the 68010 did instuction suspension instead.
The "interesting" workarounds that I've hear of are actually
68000-related. As the 68000 could not do instruction restarts, people
originally through you couldn't use it in demand paging systems.
However, I think it was Apollo (but it might have been some other
company) did come up with a solution.
The 68000 could not restart an instruction, nor suspend them and later
resume. However, you could stall the processor indefinitely.
Using their own designed MMU (there were none from Motorola for the
68000), and a second CPU, Apollo made the primary CPU stall on a page
fault, and the secondady CPU wake up. The secondary CPU could then do a
page in. Once the page was available, the primary CPU was allowed to
continue.
(One alternative version of the design that I heard was that the
secondary CPU would run in parallel with the primary, but slightly
behind, so that it could be interrupted before starting to execute the
instruction causing a page fault, and then you'd have the saved state
before the page fault in the secondary CPU, but I don't think that this
is a plausible design).
> On 2010 Oct 29, at 10:39 AM, Ethan Dicks
wrote:
> >>
> >> That all depends. ?Back in the day, what we did was not demand-paged
> >> virtual memory (something supported natively on the VAX and the 68010
> >> (but not effectively on the 68000)... (which is part of what
> >> distinguishes the 68010 from the 68000 - instruction restart).
>
> There have been a couple of indications it was the '10 that added the
> instruction restart, but was the implementation in the '10 bug-free?
I
know it works well enough in early Sun workstations and the AT&T
Unix PC (3B1/7300), but I have no knowledge of any required
workarounds due to possible bugs. > I
didn't deal with the problem directly, heard about it from some friends
> who were programming around it, and it would have been 1989, so long after
> the 00->10 transition. My recollection about the issue was there was a bug
> under certain conditions that was fixed in the next version, as distinct
> from a 'new feature', but perhaps it was just the way the problem was
> described to me or the way I understood what was being said.
I have no
memory of issues with instruction restart on the '10, but I
didn't use that feature of the chip when I was doing embedded product
development 20+ years ago (we only used it for the "loop mode"
1-instruction cache feature that allowed so-called "DBcc loops" to run
~50% faster due to not needing fetch cycles while in the loop).
Could what you remember be something to do with "instruction restart"
vs "instruction continuation"? (a distinction I was not making, but
now that I've read this -
http://www.easy68k.com/paulrsm/doc/dpbm68k1.htm - perhaps that's a
better way to describe it).