🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.arch
Article #2018

Re: Instruction (dis)continuation

#2018
From: Donald Lindsay
Date: Mon, 28 Aug 1989 17:42
39 lines
2454 bytes
In article <204@bbxeng.UUCP> scott@bbxeng.UUCP (Scott-Engineering) writes:
>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?

Well, no. Perhaps you are confusing "instruction continuation" with
"program continuation".

A normal interrupt can be ignored for a tiny amount of time. So, for
convenience, the processor will ignore an interrupt request until
the processor happens to be between instructions.

A page fault interrupt isn't like that. The instruction in progress
cannot go forward: it wants to write to a page that is out on disk
(or whatever). The interrupt has to be honored at once, and the
instruction is not completed. The operating system is invoked. The OS
does good stuff (like disk I/O) and eventually decides to let the
user program resume.  But resume where in the program? And with what
register contents, what processor state?

If the hardware has been designed to do "instruction continuation",
then the user program will resume somewhere in the middle of the
offending instruction. If the hardware has been designed for
"instruction restart", then the program will be resumed at the start
of the offending instruction. The user-visible result is the same in
both cases. 

The fun stuff comes in actually **implementing** either of these
schemes. For example, suppose the following instruction:

	load two words from @ro into r0 and r1.

What if the two words lie across a page boundary?  Hmmm!
-- 
Don		D.C.Lindsay 	Carnegie Mellon School of Computer Science
Technical Details
Message-ID: <5990@pt.cs.cmu.edu>
Path: arc1-ca.pugleaf.net!utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!pt.cs.cmu.edu!MATHOM.GANDALF.CS.CMU.EDU!lindsay
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>

Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!pt.cs.cmu.edu!MATHOM.GANDALF.CS.CMU.EDU!lindsay
From: lindsay@MATHOM.GANDALF.CS.CMU.EDU (Donald Lindsay)
Newsgroups: comp.arch
Subject: Re: Instruction (dis)continuation
Message-ID: <5990@pt.cs.cmu.edu>
Date: 28 Aug 89 17:42:27 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>
Organization: Carnegie-Mellon University, CS/RI
Lines: 39