Discussion:
[OpenRISC] Status on the GCC upstreaming effort
Christian Svensson
2014-12-30 11:43:17 UTC
Permalink
Hi,

You might recognize me from e-mails containing such words as "upstreaming",
"binutils" and "GCC".

I have not kept myself updated in the latest of OpenRISC for the last
months, so forgive me if I've missed some new developments in any of the
areas below.

I feel like I owe it to the community and the contributors to write this
public statement where we are, so here you go.

This is long overdue status update on the GCC upstreaming effort.
Back this last summer I sent out an email to all the contributors to our
GCC port to ask them to assign copyright to GNU. I also asked some people
to take a look at our GCC patches and the initial reaction was good (Thanks
Giuseppe!).

As for the assignment:
A few months later I verified the assignment status with the FSFs GNU
administration.
All the authors have successfully assigned copyright, except one whom I
have successfully reached out to but since then lost contact with. If
someone knows a Mr. M****z B**s***r and can ask him to assign copyright,
I'd be most delighted.
In any case, if anyone feels like they want to try to reach out to our last
contributor please contact we and I will supply the contact details that I
know of.

As for the code review:
We need to find a GCC code reviewer. The GCC folks informed me that we need
someone who is a 'global reviewer' and we probably need to convince someone
to do this for us, as it is a bit of work involved - understandably.

As for the code status:
Last time I tried to run the GCC testsuites I got quite the number of
failed test cases. This may or may not be issues in everything from GCC,
glibc and even Linux. Or it might be that the testcase is stupid for
OpenRISC and should be disabled. This said, I'm not convinced that we will
get a go ahead given that we haven't got a 100% pass yet. Having some
continuous testing here would be sweet if anyone would like to set that up
- or at least some way of tracking the regressions (we used to have this on
the old wiki but I don't think it has been updated).


These three blockers described above (assignment, review and testsuites)
are all too much for me to handle on my own, and that's largely why it
hasn't progressed the last couple of months.
The biggest hit on me personally would be the assignment part, as if we can
get that done we might be able to push the patches as extra patches in for
example Debian.

It's quite sad if we cannot finish it, given that we're so close. The step
where a lot of people were nervous about was the assignment, which is
really really close.

Let me know if you wonder something or want to help push this beast
forward.

Thanks for reading!
Christian
Peter Breuer
2014-12-30 22:31:59 UTC
Permalink
I ask because I have been puzzled by the 64-bit descriptions at several
points, where it looks to me as though there is some suspicion that they
may have been copy-pasted from the 32-bit description and modified only
incompletely. My apologies if that is not the case, but I would welcome
reassurance [Yes, I've checked through the "proposed changes"!]

For the MAC, MULD, etc instructions, for example, I gather from the
text and formulae that the results of 64-bit multiplication are to be
stored or accumulated as two 32-bit words in a MACHI and MACLO register.
But there is no mention of that/those target register(s) that I can find
except a reference to a "MAC unit" group (#5) of registers, and there is
no mention of how many bits the special purpose registers (I suppose
these are some) should generically have.

What's the point of multiplying two 64-bit numbers, throwing away the
top 64 bits, and storing or accumulating the bottom 64 bits as two
32-bit lumps? Or is the MACHI/MACLO notation meant to hedge some bets,
so it's just a single "MAC" register in reality? Why are additive
overflow exceptions in the accumulator signalled, but nobody takes any
notice of whether the multiplication has overflowed or not?

It would make more sense to me if multiplication were stored or
accumulated into two 64-bit registers, analogous to the 32-bit
behavior.

Anyway .. I'd be grateful for an indication of the status of these
slightly-dubious-looking-to-me 64-bit descriptions.

Regards and please keep up the good work!

PTB
Philipp Wagner
2015-01-01 23:30:54 UTC
Permalink
Hi Christian,
Post by Christian Svensson
A few months later I verified the assignment status with the FSFs GNU
administration.
All the authors have successfully assigned copyright, except one whom I
have successfully reached out to but since then lost contact with. If
someone knows a Mr. M****z B**s***r and can ask him to assign copyright,
I'd be most delighted.
In any case, if anyone feels like they want to try to reach out to our
last contributor please contact we and I will supply the contact details
that I know of.
How much code are we talking about here that's missing copyright assignment?
Post by Christian Svensson
Last time I tried to run the GCC testsuites I got quite the number of
failed test cases. This may or may not be issues in everything from GCC,
glibc and even Linux. Or it might be that the testcase is stupid for
OpenRISC and should be disabled. This said, I'm not convinced that we
will get a go ahead given that we haven't got a 100% pass yet. Having
some continuous testing here would be sweet if anyone would like to set
that up - or at least some way of tracking the regressions (we used to
have this on the old wiki but I don't think it has been updated).
Stefan Wallentowitz has set up Jenkins CI
(http://lis.ei.tum.de/jenkins/), which is already used for the newlib
port as well as some other build tests. It's probably not too hard to
add the GCC test suites to it.

Could you quickly describe what's needed to run the test suite? Then
I'll get it set up and we have at least some progress information on how
things are moving, and I'll see if I can get the test suite results into
a usable form for tracking progress.
Post by Christian Svensson
Let me know if you wonder something or want to help push this beast
forward.
Thanks Christian for your work, it's very much appreciated.

Philipp

Loading...