🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.arch
Article #2109

Re: Instruction (dis)continuation

#2109
From: R. Vuurboom
Date: Mon, 04 Sep 1989 16:53
109 lines
6018 bytes
In article <265@gp.govt.nz> GPWRDCS@gp.govt.nz (Don Stokes, GPO) writes:
>In article <205@bbxeng.UUCP>, scott@bbxeng.UUCP (Engineering) writes:
>> 
>> I remember reading some literature when the 68010 came out explaining the
>> wonderful benefits of instruction continuation and why instruction restart
>> did not always solve the problem.  (I don't remember *where* I read this.)
>> Now I'm hearing that it doesn't really matter.  Instruction restart makes
>> a lot more sense to me as long as the side effects of the instruction are
>> not not interruptable.  Is this the case with the 68040?

To begin with the last point first, its my understanding that due to
data prefetching and the restart exception model the  same location can 
sometimes be accessed twice (which can be, uhmmm, unpleasant for 
memory-mapped i/o) which is why motorola no longer claims virtual machine 
support for the 68040. My understanding could be flawed though...

But maybe we can second-guess motorola. How about the following scenario:

In order to improve perfomance, motorola decides to pipeline heavily,
heavy pipeline means a lot of data prefetching. Now with all that
prefetched data we suddenly run into an exception...problems. Best thing
is throw it all away and start anew. Now the whole point of instruction
continuation was to know which locations were already accessed. Since this 
could no longer be supported might as well go over to  the simpler 
instruction restart. So the real trade-off was performance vs virtual 
machine support.

Could this be the story behind the instruction continuation discontinuation? 
Stay tuned :-)


As for the first point:

The 68010 programmers reference manual motivates instruction continuation
as follows (1.4.1 Virtual Memory p.8):

"The MC68010 uses instruction continuation rather than instruction restart
to support virtual memory. With instruction restart, the processor must
remember the exact state of the system before each instruction is started
in order to restore that state if a page is fault occurs during its
execution. Then, after the page fault has been repaired, the entire 
instruction that caused the fault is reexecuted. With instruction
continuation, when a page fault occurs the processor stores its internal
state and then after the page fault is repaired, restores that internal
state and continues execution of the instruction. In order for the
mc68010 to utilize instruction continuation, it stores its internal
state on the supervisor stack when a bus cycle is terminated with a
bus error signal......

Instruction continuation has the additional advantage of allowing hardware
support for virtual i/o devices. Since virtual registers may be simulated
in the memory map, an access to such a register will cause a fault and the
function of the register can be emulated by software."

Now, especially in the light of preceding discussion in this group, it is
not clear to me how the first paragraph above motivates instruction
continuation above restart. Apparently the motorola folks seem to agree since
in the 68020 Users Manual we read the following (1.3.1 Virtual memory p.1-7):

"The MC68020 uses instruction continuation to support virtual memory. In
order for the mc68020 to use instruction continuation, it stores its
internal state...

...Instruction continuation is crucial to the support of virtual i/o devices
in memory-mapped input/output systems. Since virtual registers may be
simulated in the memory map, an access to such a register will cause a
fault and the function of the register can be emulated in software."

Note the two differences: first, no more mention of instruction restart
and second, what was first an "additional advantage" has now become
"crucial".

For the 68030 we see again a changed viewpoint:

In the 68030 users manual we read (in 1.6.1 Virtual Memory p.1-11):

"The mc68030 uses instruction continuation to support virtual memory..."

and in 1.6.2 Virtual Machine:

"Instruction continuation is used to support i/o devices in memory-mapped
input/output systems. Control and data registers for the virtual device are
simulated in the memory map. An access to a virtual register causes a fault
and the function of the register is emualated by software."

Note the differences: first, instruction continuation is no longer "crucial"
to support memory mapped i/o devices and second, the motorola folks have
finally figured out that memory-mapping i/o devices is a virtual machine
concept and not a virtual memory concept.

And finally of course (what started this whole thread): the 68040's
non-support of instruction continuation.

>
>I think I saw something similar in the depths of my MC68020 User's Guide
>(I love the way Motorola call the technical docs for a processor a
>"User's Guide").  Might dig it out sometime, but I think the gist of it 
>was as follows:
>
[ Example follows]

You might want to dig it out sometime since I (for one) couldn't find it.


-- 
wiskunde: Dutch for mathematics. Literally: Knowledge of certainty   
wis: certainty			kunde: 	Knowledge
Roelof Vuurboom  SSP/V3   Philips TDS Apeldoorn, The Netherlands   +31 55 432226
domain: roelof@idca.tds.philips.nl             uucp:  ...!mcvax!philapd!roelof
Technical Details
Message-ID: <241@ssp1.idca.tds.philips.nl>
Path: arc1-ca.pugleaf.net!utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!gem.mps.ohio-state.edu!ginosko!uunet!mcsun!hp4nl!philapd!ssp1!roelof
References: <AGLEW.89Aug21205533@chant.urbana.mcd.mot.com> <1989Aug24.215104.156@mentor.com> <231@ssp1.idca.tds.philips.nl> <2345@oakhill.UUCP> <204@bbxeng.UUCP> <5990@pt.cs.cmu.edu> <205@bbxeng.UUCP> <265@gp.govt.nz>

Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!gem.mps.ohio-state.edu!ginosko!uunet!mcsun!hp4nl!philapd!ssp1!roelof
From: roelof@idca.tds.PHILIPS.nl (R. Vuurboom)
Newsgroups: comp.arch
Subject: Re: Instruction (dis)continuation
Summary: Changing viewpoints (long)
Message-ID: <241@ssp1.idca.tds.philips.nl>
Date: 4 Sep 89 16:53:35 GMT
References: <AGLEW.89Aug21205533@chant.urbana.mcd.mot.com> <1989Aug24.215104.156@mentor.com> <231@ssp1.idca.tds.philips.nl> <2345@oakhill.UUCP> <204@bbxeng.UUCP> <5990@pt.cs.cmu.edu> <205@bbxeng.UUCP> <265@gp.govt.nz>
Organization: Philips Telecommunication and Data Systems, The Netherlands
Lines: 109