🚀 go-pugleaf

In article <204@bbxeng.UUCP> scott@bbxeng.UUCP (Scott-Engineering) writes:
>
>   In article <2345@oakhill.UUCP> shebanow@oakhill.UUCP (Mike Shebanow) writes:
>    In article <231@ssp1.idca.tds.philips.nl> roelof@idca.tds.PHILIPS.nl
>    (R. Vuurboom) writes:
>    
>    >I've noticed that motorola has moved from instruction continuation
>    >(68010-30) to instruction restart (68040). So they no longer support
>    >virtual machines. (Must be the processors got tired of puking their
>    >insides all over the stack. :-)
>    >
>    >[...]
>    
>    You can still emulate virtual machines using instruction restart.  All 
>    you have to do is simply interpret the instruction which faulted :-\
>    That is, when the machine takes the exception, the stack frame will point
>    to the offending instruction.
>
>Forgive me for showing my ignorance, but, doesn't instruction continuation
>enable features such as dynamic stack allocation?  Are we doomed to
>return to the antiquated "stack probe"?  Does this mean that 68030
>(user mode) software will not always work correctly on the 68040?
>What about page faults?  Is the operating system *really* expected 
>to include an instruction set interpreter so it can simulate
>instruction continuation?  The 386 is suddenly starting to look good
>me.
>
>---------------------------------------
>Scott Amspoker
>Basis International, Albuquerque, NM
>505-345-5232

Sorry about the long reply.

I believe (but I am willing to be proved wrong) that anything that can
be done using instruction continuation can also be done using restart.
This includes dynamic stack allocation.  Using that as an example, when
a stack overrun occurs (decrements below allocated memory), a page fault
will occur.  In the restart model, the offending instruction will be
undone.  In general, most machines using restart will store exception
cause information in supervisor visible registers.  This will indicate
why the exception occurred (MMU fault), what happened (translation not valid -
page fault), where it happened (some virtual address - In Unix for example,
a stack fault would be obvious by inspection of the address) and other
pertinent information.  Once the operating has determined the cause, it
can allocate new memory and simply restart the instruction. Assuming that
there are no other problems with the offending instruction, all will
proceed as normal.

In response to your question about interpreters in operating systems,
no, I don't think an operating using a restart machine needs to have
a built-in interpreter.  Page faults, for example, would be handled in
a manner similar to the way stack faults are handled: the fault gets
logged in hardware registers and restart is used to reexecute the faulting
instruction once the page has been swapped in.  The OS doesn't need any
more detailed information than that.  

So when is an interpreter necessary?  If a complete virtual machine
is to be emulated, and such a machine includes such things as virtual
memory mapped I/O devices, then interpretation may be necessary.
For example, assume that some type of I/O device is mapped into user
memory.  The OS wants the user to be able to read the device normally, but
if a write is attempted, some other action should happen.  BUT, the OS
wants the user program to think that it HAS written the device.  In
certain machines (which support memory-memory operations), a read may have
happened to the device and before the write part of the instruction attempts
to write the device.  If the reading the device is destructive (meaning
you can only read it once), you cannot use restart on the instruction.
If you did, you would read the device twice.  In this particular case, it
might be necessary for the OS to complete the instruction on behalf of
the hardware.

The only real difference between a restart machine and a continuation machine
is (a) how much work needs to be done by hardware to save enough
state so that instruction restart or continuation is possible and (b)
how much work needs to be redone once the problem is corrected.

Mike Shebanow
--------------
Disclaimer: the opinions presented here are my own, not Motorola's.