Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Lawrence D'Oliveiro <ldo@nz.invalid>
Newsgroups: comp.arch
Subject: Re: First-Part-Done (was Re: Byte Addressability And Beyond)
Date: Mon, 3 Jun 2024 08:20:48 -0000 (UTC)
Organization: A noiseless patient Spider
Lines: 17
Message-ID: <v3jud0$3qduu$9@dont-email.me>
References: <v0s17o$2okf4$2@dont-email.me> <v34v62$ln01$1@dont-email.me>
	<7yn5O.33584$9xU7.29321@fx17.iad> <v39caf$1jtgk$1@dont-email.me>
	<v3a386$14g8$1@gal.iecc.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Injection-Date: Mon, 03 Jun 2024 10:20:49 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="d9da7b9b9ad3ac546e12baaad0ff5901";
	logging-data="4011998"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX197303/HB7/XD7+SIW0PB1B"
User-Agent: Pan/0.158 (Avdiivka; )
Cancel-Lock: sha1:Hyyiw30/TMhVFD7ndPcb9nOYBGE=
Bytes: 1880

On Thu, 30 May 2024 14:42:14 -0000 (UTC), John Levine wrote:

> The condition code tells you which it was.  If it was an interrupt, you
> just branch back and keep going.

Does it really hurt performance for the CPU to keep track of the fact that 
an instruction has to be restarted after an interrupt?

On the old VAX, there was a processor status bit called “First Part Done”, 
which was used for interruptible instructions. When an interrupt happened 
with such an instruction, the PC was not incremented past the instruction; 
instead, the saved PC pointed back at the instruction itself, while the 
saved processor status had the FPD bit set.

So on a return from the interrupt, the CPU knew not to redo the 
instruction setup, but just continue executing the instruction from the 
current register state.