Bug 355 - game theory "state" packet engine needed
Summary: game theory "state" packet engine needed
Status: CONFIRMED
Alias: None
Product: Libre-SOC's first SoC
Classification: Unclassified
Component: Source Code (show other bugs)
Version: unspecified
Hardware: Other Linux
: --- enhancement
Assignee: Luke Kenneth Casson Leighton
URL:
Depends on:
Blocks:
 
Reported: 2020-05-27 22:04 BST by Luke Kenneth Casson Leighton
Modified: 2020-07-21 14:16 BST (History)
1 user (show)

See Also:
NLnet milestone: ---
total budget (EUR) for completion of task and all subtasks: 0
budget (EUR) for this task, excluding subtasks' budget: 0
parent task for budget allocation:
child tasks for budget allocation:
The table of payments (in EUR) for this task; TOML format:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Luke Kenneth Casson Leighton 2020-05-27 22:04:35 BST
it occurred to me that the branch system etc. is basically running game theory (in hardware), running new "state" ahead.

the program counter, DEC SPR, and TB SPR, these all increment and need rollback in a group.  there may also be other pieces of state information involved.

my feeling is that we will need a ring buffer, associated with the instruction queue (or actually part of it) that contains each advancement of that state, and thus we can roll it back without losing anything.

perhaps it is as simple as adding DEC and TB to the Decode2ExecuteType data structure?
Comment 1 Luke Kenneth Casson Leighton 2020-05-27 22:42:32 BST
some possible ideas which preserve the state/context:

* a ring buffer with the instruction, TB, DEC and other context as entries is created.  the index of the ring buffer entry is passed down the pipeline "ctx" (context)

* TB, PC and DEC are passed into "ctx".  as this is 3x 64 bit that is an awful lot, it will be copied right the way through the pipelines (and not actually change or be used).

* a separate instruction queue and a separate ring buffer for state.