[Libre-soc-isa] [Bug 908] indexed remap needs defined behavior for out-of-bounds indexes

[bugzilla-daemon at libre-soc.org]

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

--- Comment #3 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
the (In reply to Jacob Lifshay from comment #2)
> (In reply to Luke Kenneth Casson Leighton from comment #1)

> you don't have to do the comparisons in instruction issue...

then that forces a Hazard Dependency which is exactly what is to be
avoided.

> for reads, they can be done in the alu or register read or operand
> forwarding stages, 

no chance.

i already said that that goes into a Shadow Cancellation
Matrix

> all you need is to and the value with 0/-1 as appropriate
> for the index<VL comparison.

"all"... going into an unnecesaary Shadoe Matrix.

> for writes, they can be merged into the predicate mask at any stage before
> forwarding outputs to succeeding operations or writing to output registers.

predicate masks require Shadow Matrices.

you are asking for ywt another Shadow Matrix to be added.

the answer is, has been said once already, and is now onto the
second repetition:

no.



> also, even if you did do the comparisons in instruction issue, the
> comparisons can be done simultaneously to instruction decode/issue, 

second reptition: too coatly.

i said no to this once already.

tbe answer doea not change: no


> the
> results aren't needed to decode the instruction. the comparison results can
> be ignored if it's not an indexed op, so the comparison logic can be built
> to assume it is an indexed op and the invalid results will be ignored when
> the assumption is wrong.

that is the definition of requiring a Shadow Matrix.

> > i specifically designed it so that the implementor
> > may cache the Indices then completely ignore normal
> > Register Hazards, safe that the programmer knows
> > what to expect and what not to do.
> > 
> > wasm swizxle, good for them, not relevant. swizzle
> > is static, this is dynamic.
> 
> you missed what I stated, wasm's i8x16.swizzle *is* a *dynamic* shuffle and
> requires out-of-bounds accesses to return zero.

that's great for them.  it can be done with a sv.cmp creating
a predicate mask.


> no, the out-of-bound index change the register read to explicitly return
> zero.

not happening.

> > 
> > Traps are the worst thing to do as well, those require
> > Shadow Matrix Entries.  a hot-loop triggers Traps?
> 
> yes, hence why I left that as an alternative rather than my preferred choice.

issue is where the hardware for loop lives.  it interacts directly with
the Register Hazard Allocation, even as far back as Decode.

the only reason to be able to get away with the hardware forloops prior to
Indexing bwing added was because they are 100% deterministic and rely on
SPRs not regs (change MAXVL etc and it is normal to have some latency).

IBM's hardware engineers will grumble about that but it is reasonably
explainable and reasonable to have 8-way multi-issue Deterministic
computation of QTY 8 sets of Register Hazards at once (even with Matrix REMAP).

throw in Indexed REMAP where it becomes necessary to look up EIGHT
simultaneous Indices to create 8 simultaneous Register Hazards and
they are going to get very concerned until the rules "No Hazards" on
the Indices are explained, at which point i expect them to calm doen 

to then try adding comparisons into that either in Decode or Issue
they are going to blow a fuse and with good reason.

the answer is no, and will remain no.

a useful task that you could do is create a small substitution table
cipher (a toy one) e.g. a substitution table of 16 entries and show
how sv.cmp would work.

if you are ok to do that or come uo with other algorithms that fit
Indexed REMAP *as designed* i will keep the bugreport open, otherwise
i will close it as invalid.

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