Path: 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: <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 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: 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