[Libre-soc-bugs] [Bug 550] binutils support needed for svp64

[bugzilla-daemon at libre-soc.org]

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

--- Comment #10 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to lechenko from comment #9)
> (In reply to Luke Kenneth Casson Leighton from comment #8)
> 
> Slowly but surely, I figured out, what
> https://git.libre-soc.org/?p=openpower-isa.git;a=blob;f=src/openpower/sv/
> trans/svp64.py;h=45b292b4c4c32bbff548f2bf299235633d31db6c;hb=HEAD#l1052
> does. 
> 
> As I understood, it translates svp64 asm mnemonics to prefix as a 32-bit
> literal and subsequent scalar OpenPOWER asm mnemonic.

because there is no binutils support for svp64, yes.  when the .long
and the 32 bit mnemonic get passed to binutils, they get converted to
binary *without* binutils ever needing to know anout svp64 assembler.

the exercise is therefore to merge the EXACT functionality of svp64.py
*into* binutils.


> And after that
> translated .S-file feeds to binutils to produce binary file.

yes.

> So, now we want to support the same svp64 asm mnemonics directly in
> binutils. But, my guess, that scalar OpenPOWER instructions are already
> there. 

yes, and yes.

> Thus, few questions.
> 
> Does it mean, that we can try to implement the same two-step translation
> logic inside binutils?

yes, exactly. or, more to the point: after "conversion" to ".long xxxxx;
{equivalent v3.0B}" pass that *again* to the relevant function and get it to
convert those to the appropriate binary output.

it is important to do that conversion pass *after* all the macro renaming
and expansion of registers.  gas has a builtin macro system, you cannot
process SVP64 registers until you know the actual number, 0-127.


> Or reuse OpenPOWER-related header files, at least?

yes absolutely, for goodness sake don't duplicate the entirety of power isa
headers for scalar operations.


> Another one about svp64 asm syntax. As far as I understand, it is already
> support current version of asm syntax, but is there a spec on it? Could you
> share a link, please.

there is a spec, http://libre-soc.org/openpower/sv/svp64 however
i literally made up the syntax as i went along.

"need a way to indicate mapreduce, err "mr" is short, that'll do"

no kidding! :)

svpy4.py is pretty much it, alongside the consts.py and other data structures,
power_enums.py and so on.

svp64.py and the Decoder are the canonical sources at the moment until
such time as there *is* time for someone *to* write documentation like
this.


> And the last one, for now. I guess, I can reuse/refactor both sv_analysis.py
> and svp64.py to generate header for binutils. Was that your intentions on
> how to do that task?

yyyep!  or, err refactor svp64.py? ahh more, "use svp64.py as a reference
to create the exact same thing in c", and *add* to sv_analysis.py to get
it to output autogenerated headers for use in binutils.  if you look
at how the microwatt vhdl struct is autogenerated that is pretty much
exactly what is needed.

cut, paste, substitute right magic constants, done.

you will see there are some data structures in binutils headers, that list
instructions.

if you add *one* extra field to that (a pointer to a binutils-ppc-svp64-struct)
ordinarily by leaving that out of the existing structs it will default to NULL.

you can then autogenerate a binutils svp64 header full of ppc-svp64-struct
entries then have a function which, before use, *fills in*, *at runtime*, the
pointers.

btw you got the message about copyright assignment to the FSF? this is *really*
important.  binutils code that has not had an FSF copyright assignment *cannot
be accepted upstream* and whatever you did would have to be thrown away and
duplicated by someone who has.

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