Re: fractional PCs

Liste des GroupesRevenir à c arch 
Sujet : Re: fractional PCs
De : robfi680 (at) *nospam* gmail.com (Robert Finch)
Groupes : comp.arch
Date : 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.

Date Sujet#  Auteur
6 Nov 24 * Re: Q+ Fibonacci57Robert Finch
17 Apr 25 `* Re: register sets56Robert Finch
17 Apr 25  +* Re: register sets53Stephen Fuld
17 Apr 25  i+- Re: register sets1Robert Finch
17 Apr 25  i+* Re: register sets46MitchAlsup1
18 Apr 25  ii`* Re: register sets45Robert Finch
18 Apr 25  ii `* Re: register sets44MitchAlsup1
20 Apr 25  ii  `* Re: register sets43Robert Finch
21 Apr 25  ii   `* Re: auto predicating branches42Robert Finch
21 Apr 25  ii    `* Re: auto predicating branches41Anton Ertl
21 Apr 25  ii     +- Is an instruction on the critical path? (was: auto predicating branches)1Anton Ertl
21 Apr 25  ii     `* Re: auto predicating branches39MitchAlsup1
22 Apr 25  ii      `* Re: auto predicating branches38Anton Ertl
22 Apr 25  ii       +- Re: auto predicating branches1MitchAlsup1
22 Apr 25  ii       `* Re: auto predicating branches36Anton Ertl
22 Apr 25  ii        `* Re: auto predicating branches35MitchAlsup1
23 Apr 25  ii         +* Re: auto predicating branches3Stefan Monnier
23 Apr 25  ii         i`* Re: auto predicating branches2Anton Ertl
25 Apr 25  ii         i `- Re: auto predicating branches1MitchAlsup1
23 Apr 25  ii         `* Re: auto predicating branches31Anton Ertl
23 Apr 25  ii          `* Re: auto predicating branches30MitchAlsup1
24 Apr 25  ii           `* Re: asynch register rename29Robert Finch
27 Apr 25  ii            `* Re: fractional PCs28Robert Finch
27 Apr 25  ii             `* Re: fractional PCs27MitchAlsup1
28 Apr 25  ii              `* Re: fractional PCs26Robert Finch
28 Apr 25  ii               +* Re: fractional PCs15MitchAlsup1
29 Apr 25  ii               i`* Re: fractional PCs14Robert Finch
5 May 25  ii               i `* Re: control co-processor13Robert Finch
5 May 25  ii               i  `* Re: control co-processor12Al Kossow
5 May 25  ii               i   `* Re: control co-processor11Stefan Monnier
6 May 25  ii               i    +* Re: control co-processor3MitchAlsup1
7 May 25  ii               i    i+- Re: control co-processor1MitchAlsup1
15 Jul 25  ii               i    i`- Re: control co-processor1MitchAlsup1
7 May 25  ii               i    `* Scan chains (was: control co-processor)7Stefan Monnier
7 May 25  ii               i     +* Re: Scan chains (was: control co-processor)2Al Kossow
7 May 25  ii               i     i`- Re: Scan chains1Stefan Monnier
7 May 25  ii               i     +* Re: Scan chains3MitchAlsup1
7 May 25  ii               i     i`* Re: Scan chains2Stefan Monnier
8 May 25  ii               i     i `- Re: Scan chains1MitchAlsup1
15 Jul 25  ii               i     `- Re: Scan chains1MitchAlsup1
29 Apr 25  ii               `* Re: fractional PCs10Robert Finch
29 Apr 25  ii                `* Re: fractional PCs9MitchAlsup1
30 Apr 25  ii                 `* Re: fractional PCs8Robert Finch
30 Apr 25  ii                  +* Re: fractional PCs6Thomas Koenig
1 May 25  ii                  i+- Re: fractional PCs1Robert Finch
2 May 25  ii                  i`* Re: fractional PCs4moi
2 May 25  ii                  i +* Re: millicode, extracode, fractional PCs2John Levine
2 May 25  ii                  i i`- Re: millicode, extracode, fractional PCs1moi
2 May 25  ii                  i `- Re: fractional PCs1moi
30 Apr 25  ii                  `- Re: fractional PCs1MitchAlsup1
15 Jul 25  i`* Re: register sets5John Savard
15 Jul 25  i `* Re: register sets4MitchAlsup1
19 Jul 25  i  `* Re: register sets3Robert Finch
19 Jul 25  i   `* Re: register sets2Anton Ertl
19 Jul 25  i    `- Re: register sets1MitchAlsup1
15 Jul 25  `* Re: register sets2John Savard
15 Jul 25   `- Re: register sets1MitchAlsup1

Haut de la page

Les messages affichés proviennent d'usenet.

NewsPortal