[Libre-soc-bugs] [Bug 1177] revert unauthorized change to pseudocode language

[bugzilla-daemon at libre-soc.org]

https://bugs.libre-soc.org/show_bug.cgi?id=1177

--- Comment #4 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to Jacob Lifshay from comment #3)
> imo a better approach is to have the simulator read all destination
> registers

nom nom nom.. thinking it over... this is a great idea / principle. i don't
know why it wasn't brought up before now :)

how to implement without causing chaos on some of the "overwrite" instructions
like ternlogi...

where, there, if done naively (always-write-back) the fact that the
instruction may choose any one of *3* registers to write-back, the
simulator could write *all* of them, corrupting results.

so... a solution to that: mirror what is in TestIssuer, with the
data/ok flag.  if you *really* want the register written, you set
the "ok" flag.

> (marking the reads as ignored for the in-order pipeline simulator)
> before executing the pseudo-code, so *any* conditional overwrites will work
> without needing any vex_flags special casing (special casing should be
> avoided whenever possible).

yes i never liked it (overflow-hack) but it worked pending a better solution.
this is a better solution.

> this also matches what a reasonable reader would
> expect the pseudocode to mean, where any unwritten outputs keep their
> original values.
> 
> so, like:
> if (RA) = 0 then
>     RT <- (RB)
> 
> would approximately translate to:
> def op_theinsn(self, RA, RB, RT):
>     if eq(RA, 0):
>         RT = copy_it_icr_the_name(RB)
>     return (RT,)

better:

     if eq(RA, 0):
         RT = copy_it_icr_the_name(RB)
         RT.ok = True
     return (RT,)

which then back in ISACaller it is detected "if outputreg.ok then store"

> the way i saw it is that the pseudocode still described completely what's
> happening, the html comment is not part of the pseudocode and is merely
> there to inform our simulator that its overly-simplistic analysis of what
> registers need to be passed into the translated pseudocode need RT added too.

unfortunately it becomes part of the entire process, the storage of
information,
about how to do what needs to be done in the compiler / simulator.

for example, now the c-based compiler *also* needs to know about that HTML
parsing!

which is... bad.

> imo our project is to the size where *everyone* should be working in
> separate branches and then merging to master only after both someone else
> okays the changes *and* CI passes on their branch.

well, it's more that *if* everyone had the same level of working-knowledge
that i do (because i have been doing or working closely with literally
everything, hundreds of thousands of lines of code, now) *then* it would
not be necessary.

as the only person with the full working knowledge, it is "safe" for me to not
need CI, and to work in the master branches, but most definitely definitely
*not* safe for anyone else.

that was a mistake made by me to assume that everyone else would be able to
keep up - they can't, we know that now.

actually... this needs to go on the list. and also bug #1126. let's transfer
there.

in the meantime, back on topic for this bug: do let me know what you think
about the "ok" flag idea.

-- 
You are receiving this mail because:
You are on the CC list for the bug.