30 Oct
2010
30 Oct
'10
3: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). 
31 Oct
31 Oct
8:21 a.m.
New subject: 68K
Johnny Billquist wrote:
Apollo [...] Using their own designed MMU (there were
none from
Motorola for the 68000),
The MC68451 was an MMU for the MC68000/010/012. It
didn't use
fixed-size pages, but it definitely was an MMU.
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.
With instruction continuation, it most definitely was not "all preserved
internally in the CPU"; if that were done you'd be in big trouble if you
did a context switch to another process then it got a bus error also.
On the MC68010/012/020/030, when a bus fault or address fault happened,
a big block of internal CPU state was puked onto the stack. As a
consequence, the stack frames used for all exceptions (not just bus
error and address error) were different than those of the MC68000/008.
That most definitely does expose the software to something new. An
operating system for the MC68000/008 generally could not be used on the
MC68010/012/020/030 without modification.
Alternatively, instruction continuation could have left the partially
completed instruction state in programmer-visible special registers, as
was done for instruction restart in the high-end PDP-11 models. Then
the software could either handle the page fault immediately, or save
those register on the process stack or in a process control block, and
handle the page fault later.
On a CISC, there's a potential problem with instruction restart, which
is that if there aren't enough free MMU pages available, you can get
into a situation where an instruction can never complete execution.
When you try to execute it, you read the first word of the instruction,
but get a page fault reading the second word of the instruction which is
in the next virtual page and not resident. The page fault handler may
page out the page containing the first instruction word, and page in the
page containing the second instruction word, then try to restart the
instruction. Now it gets a page fault when reading the first
instruction word. This is a trivial example, but on a complicated CISC
an instruction may have to touch a lot of pages (on the order of a dozen
in some cases), and if the software doesn't map them all simultaneously,
the instruction can never execute to completion.
With instruction continuation, as long as the entire processor state
relevant to the partial execution of the instruction is preserved (as is
the case on the MC68010/012/020/030), even a complex instruction
touching many pages can continue to make progress as long as at least a
single MMU page can be devoted to the process.
Eric
1 Nov
1 Nov
8:51 a.m.
On Sat, Oct 30, 2010 at 6:51 AM, Johnny Billquist <bqt at softjar.se> wrote:
On 2010-10-30 01:12, Ethan Dicks<ethan.dicks at
gmail.com> wrote:
Yes. I was previously unaware of the distinction but did know what
the 68000 could not do that the 68010 could.
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.
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...
Using their own designed MMU (there were none from
Motorola for the 68000),
What about the 68451? (we had one in a prototype product design in
1984/1985 that never made it to market)
It wasn't terribly popular, but it did exist.
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...
That sounds like the design of the Perkin-Elmer workstation I have -
two 68000s, one for running the OS, one for paging.
-ethan
4947
days inactive
4949
days old
2 comments
3 participants
participants (3)
-
bqt＠softjar.se -
eric＠brouhaha.com -
ethan.dicks＠gmail.com