[Libre-soc-dev] daily kan-ban update 24nov2021

[Luke Kenneth Casson Leighton]

* helping veera with subfic
* helping dmitry clarify binutils/gas work needed
* sorted out an error in the FSM version of TestIssuer
  (accidentally enabled hazard-checking)
* abandoned use of a regfile for the bitvectors and used
   R-Priority SRLatch (actually a DFF but hey) instead.
* fixed write-after-write hazard detection
* wrote a unit test for write-to-same-read-register
   (addi 5, 5, #2)

this latter - write-to-same-read-register - is going to throw a
royal spanner in the works of the entire engine.  i need to
think about it, and to be absolutely honest, with having worked
out that the current hazard bitvectors are absolutely identical
in every single possible way to FU-Regs Dependency Matrices,
and now having hit write-to-same-read-register which is easily
solved by (get this:) deploying a FU-FU Dependency Matrix,
i'm considering moving entirely to a standard 6600 precise-augmented
design.

the amount of time it would take to arse about re-inventing how
to protect write-to-same-read-register instructions - and also have
those instructions also be protected by both read-after-write
and write-after-read hazards, is sufficiently great that it's worth
considering just going "screw it" and doing 6600 scoreboards
properly.

the write-to-same-read register protection is covered in a ridiculously
simple fashion in FU-FU Dependency Matrices:

where the row number equals the column number, the latches
are NOT CONNECTED.

this represents the situation where any given FU is NOT dependent...
ON ITSELF... for either read-after-write or write-after-read hazards.

absolutely dead simple.

right now there is a great big ORing going on of the bitvectors,
which substitutes for that FU-FU Matrix.  trying to work out
how the hell to exclude the case where FU-depends-on-itself
is precisely and exactly what an FU-FU Matrix does, is, honestly,
i feel, a waste of time, given that the solution is, quite frankly,
likely to end up duplicating FU-FU Dependency Matrices.

gaah.

l.

---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68