🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.arch
Article #2029

Re: Instruction (dis)continuation

#2029
From: John Mashey
Date: Mon, 28 Aug 1989 21:11
43 lines
2636 bytes
In article <5990@pt.cs.cmu.edu> lindsay@MATHOM.GANDALF.CS.CMU.EDU (Donald Lindsay) writes:
>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?......
.....
>Well, no. Perhaps you are confusing "instruction continuation" with
>"program continuation".
.....
>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.

I think this last must have meant @r0 into r0 and r1.

All of this is why most RISC machines:
	a) Use load/store architectures, with zero (or very few)
	side-effects.
	b) Generally require loads/stores to access aligned data
	objects, or (more generally), at least forbid any kind
	of load/store from crossing a boundary.
	c) Usually do instruction-retart, or something close.
	Note that restart-vs-continue is not a binary decision.
	Some CPUs that mostly do restart may have some flavor of
	continuation in certain cases, i.e., with imprecise exceptions,
	and sometimes with branch-delay-slot things, or with
	emulation of missing FPUs, etc, etc.
	The more fundamental issue is how much state does it take
	to figure out where you were and get back there.  At the
	minimum, this is just a PC.  At worst, the processor dumps at
	lot of mysterious stuff somewhere.
-- 
-john mashey	DISCLAIMER: <generic disclaimer, I speak for me only, etc>
UUCP: 	{ames,decwrl,prls,pyramid}!mips!mash  OR  mash@mips.com
DDD:  	408-991-0253 or 408-720-1700, x253
USPS: 	MIPS Computer Systems, 930 E. Arques, Sunnyvale, CA 94086
Technical Details
Message-ID: <26418@winchester.mips.COM>
Path: arc1-ca.pugleaf.net!utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.csd.uwm.edu!bionet!ames!vsi1!wyse!mips!mash
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>

Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.csd.uwm.edu!bionet!ames!vsi1!wyse!mips!mash
From: mash@mips.COM (John Mashey)
Newsgroups: comp.arch
Subject: Re: Instruction (dis)continuation
Message-ID: <26418@winchester.mips.COM>
Date: 28 Aug 89 21:11:24 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>
Reply-To: mash@mips.COM (John Mashey)
Organization: MIPS Computer Systems, Inc.
Lines: 43