[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 #12 from lechenko at bsuir.by ---
(In reply to Luke Kenneth Casson Leighton from comment #10)
> (In reply to lechenko from comment #9)
> > (In reply to Luke Kenneth Casson Leighton from comment #8)
> > 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.

Okay, I shall find that function then.

> 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.
> 

You mean, the conversion of 'sv.*' instruction to '.long xxxxxx; \1'? Will this
macro/expansion machinery work correctly on 'sv.*' instruction?


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

Aha. This is a binary format spec and there is no spec for mnemonics per se. My
guess, that I have to dig out the format from svp64.py and tests.

Also, forgot to mention last time. There are some macro processing in svp64.py.
Where can I read about it?

> 
> 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.

I noticed the email. But had no time to fill in and send. I'll deal with
paperwork as soon as I'll start hacking binutils.

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