Sujet : Re: fractional PCs
De : robfi680 (at) *nospam* gmail.com (Robert Finch)
Groupes : comp.archDate : 28. Apr 2025, 03:32:52
Autres entêtes
Organisation : A noiseless patient Spider
Message-ID : <vumpcl$2a0rl$1@dont-email.me>
References : 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
User-Agent : Mozilla Thunderbird
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.