Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: Robert Finch <robfi680@gmail.com>
Newsgroups: comp.arch
Subject: Re: fractional PCs
Date: Sun, 27 Apr 2025 22:32:52 -0400
Organization: A noiseless patient Spider
Lines: 55
Message-ID: <vumpcl$2a0rl$1@dont-email.me>
References: <vbgdms$152jq$1@dont-email.me> <vtsbga$1tu26$1@dont-email.me>
 <b8859e8d6b909a4505c0f487a6a0fe35@www.novabbs.org>
 <vu2542$38qev$1@dont-email.me> <vu46su$1170i$1@dont-email.me>
 <2025Apr21.080532@mips.complang.tuwien.ac.at>
 <d47cdad26528b4d2309ac9df60120315@www.novabbs.org>
 <2025Apr22.071010@mips.complang.tuwien.ac.at>
 <DwONP.2213540$eNx6.1757109@fx14.iad>
 <2025Apr22.193103@mips.complang.tuwien.ac.at>
 <f5e5bf81ac2c7e2066d2a181c5a70baf@www.novabbs.org>
 <2025Apr23.194456@mips.complang.tuwien.ac.at>
 <126700f99b6f97d7483bb5355d68c361@www.novabbs.org>
 <vucbbe$mvlc$1@dont-email.me> <vul4r4$n19o$1@dont-email.me>
 <0b410ad93124778a2b1b3ab8fb6ec62c@www.novabbs.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Mon, 28 Apr 2025 04:32:54 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="18c8ae079e36c536b22a89c21e89b1d8";
	logging-data="2425717"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+clJSJST7Ukzz40g0lDWvcaUznCmGLhow="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:eWM6fmOIxjQedjST9qGx4e6LAPc=
Content-Language: en-US
In-Reply-To: <0b410ad93124778a2b1b3ab8fb6ec62c@www.novabbs.org>
Bytes: 4197

On 2025-04-27 4:53 p.m., MitchAlsup1 wrote:
> On Sun, 27 Apr 2025 11:36:05 +0000, Robert Finch wrote:
> 
>> Representing the PC as a fixed-point number because it records which
>> micro-op of the micro-op stream for an instruction got interrupted. It
>> was easier to restart the micro-op stream than to defer interrupts to
>> the next instruction.
> 
> Why not just backup to the instruction boundary ??

I think I was worried about an instruction disabling interrupts or 
causing an exception that should be processed before the interrupt 
occurred. (keeping the interrupt precise). I did not want to need to 
consider other exceptions that might have occurred before the interrupt.

Searching for an instruction boundary in either direction is I think 
more logic than just recording the micro-op number. It is more FFs to 
record the number, but fewer LUTs. There is like 8 x10 bit comparators 
plus muxes on the re-order buffer to backup to the instruction boundary 
and mark an interrupts. Just recording the micro-op number is just 
stuffing 3 bits into the PC, plus three bits propagated down the 
pipeline (FFs). The PC has two zero bits available already.

> 
>> The lead micro-ops on a interrupt return are just NOP'd out. ATM there
>> is no micro-op state that needs to be saved and restored through context
>> switches, other than the index into the stream which can be saved as
>> part of the PC.
> 
> Also note: this is "completion" interrupt model used in 010, 020, 030
> {Not sure about 040}.
> 
> It caused:
> a) a bunch of bugs
> b) a lot of strange stack state
> c) which could be attacked by any thread with privilege.
> 
> Although it "sounds" like it saves {time, energy, forward progress}
> the state saving/restoring on the stack pretty much consumes all of
> that.

a) is a bit worrisome. Doing something out of the ordinary is always 
asking for bugs. I am guessing programmers tried to manipulate the stack 
state on the 68k series. I replicated the 010 as an FPGA core and IIRC I 
stuff the machine state number onto the stack. Which is bound to be a 
different number than the 010.
b) There is no state that needs to be stacked outside of what is 
normally stacked for an interrupt. For c) the usual interrupt as well 
could be attacked by a thread with privilege.

I have coded it both ways, so I may make it a core option. Right up 
there with page relative branching. There is already a flag to generate 
the core for performance instead of size.