[Libre-soc-bugs] [Bug 1157] Implement poly1305

[bugzilla-daemon at libre-soc.org]

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

--- Comment #40 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to Sadoon Albader from comment #38)
> (In reply to Luke Kenneth Casson Leighton from comment #35)
> > sadoon read this unit test.
> > 
> > https://git.libre-soc.org/?p=openpower-isa.git;a=blob;f=src/openpower/
> > decoder/isa/test_caller_svindex.py;h=36bb6e837;hb=191a4b0cf#l92
> 
> Looking at this unit test again after toying with it and changing values
> here and there and I now understand much better.
> 
> I had expected the values to be filled with ASM as well, but here we're
> (understandably) using python to override the registers as it's much simpler
> that way.
> 
> The obligatory question then:
> 
> Would it be reasonable to just prepare the registers with the data we need
> and just do the SVP64 parts in ASM? 

as incremental *partial* unit tests... where you do say the h0/1/2 calculation
and only have say 3 lines of assembler... absolutely yes!  if you look
at comment #3 that's *exactly what i suggest*!

> Also by extension, setting svstate.x to
> the needed values might help me finish up the implementation faster.

yes, as we just discussed here about how svindex unit test does precisely
that... yes.  but again, see comment #3, you should do *sub* tests only
that way, and *SLOWLY* build up to a larger (full, complete) functio
that doesn't do that trick
https://libre-soc.org/meetings/sync_up/sync_up_2023-11-21/


> Even if
> we needed the actual SVP64 ASM in the end, I'd at least get to a known
> working state that I can translate to ASM.

eexactly.

> I hope I'm making sense :)

indeed - you can see in comment #3 and from other tests that this is
precisely what i expected you to do as it has worked well for me for years :)

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