1/1 
|
Re: OpenRisc Digest, Vol 1, Issue 12
by Unknown on Dec 19, 2003 |
Not available! | ||
|
But we should strive to have a common one for the majority of the
community. I agree a 100%. Options we have now are: 1) using Scott Furmans gcc patch. This seems to require Scott's linker fix, we've seen eCos static constructors fail without. 2) using the University Cantabria port, which was backported by me for gcc-3.2.3. 3) making some other fix to the opencores cvs version 4) using UC-gcc-3.4 The more reasonable options are 1 and 2, the others are just included for completeness. 3) would mean senseless extra work that no one will do, 4) is not an option yet, because uc-gcc-3.4 is built on a developmental version of gcc-3.4. Maybe when gcc-3.4 gets released? Since both options 1 and 2 are available right now, I suggest we should choose one of them using the following criteria. a) is the compiler bug-free? All OS maintainers and users satisfied? b) Size of resulting binaries? c) Speed of resulting binaries? d) should we do the ABI change going with scott furmans version? My comments: a) No signs of compiler bugs with my version and eCos. Scott's also been using his version for some time, no problems there either. b) Got 8% smaller binary with my compiler. Only a single test case, not a qualified survey. c) No data. d) No one seemed to have any substantial reasons why the ABI shouldn't be changed. There were some concerns from Pablo Huerta, saying the ABI change wouldn't be the best solution. Scott said the calling conventions he's using for 64 bit values are more efficient than in the classic ABI. Regards, Heiko |
|||
|
Re: OpenRisc Digest, Vol 1, Issue 12
by Unknown on Dec 19, 2003 |
Not available! | ||
|
Since UC's gcc-3.4 has what's thought to be the best mix of OC and
UC compiler we'll use that to continue development. For the gcc-3.2.3
series i'll commit Heiko's backport patch. This way we the unified
compiler:
- stable version gcc-3.2.3 (got by Heiko's patch)
- development gcc-3.4
I think we should also work on merging the or32 port into
official gcc tree. Pablo could you send just the or32 patch for gcc-3.4,
so we can update it if neccessery and send it to gcc maintainers.
regards,
p.
* Heiko Panther (heiko.panther@web.de) wrote:
>But we should strive to have a common one for the majority of the
I agree a 100%. Options we have now are:
1) using Scott Furmans gcc patch. This seems to require Scott's linker
fix, we've seen eCos static constructors fail without.
2) using the University Cantabria port, which was backported by me for
gcc-3.2.3.
3) making some other fix to the opencores cvs version
4) using UC-gcc-3.4
The more reasonable options are 1 and 2, the others are just included
for completeness. 3) would mean senseless extra work that no one will
do, 4) is not an option yet, because uc-gcc-3.4 is built on a
developmental version of gcc-3.4. Maybe when gcc-3.4 gets released?
Since both options 1 and 2 are available right now, I suggest we should
choose one of them using the following criteria.
a) is the compiler bug-free? All OS maintainers and users satisfied?
b) Size of resulting binaries?
c) Speed of resulting binaries?
d) should we do the ABI change going with scott furmans version?
My comments:
a) No signs of compiler bugs with my version and eCos. Scott's also been
using his version for some time, no problems there either.
b) Got 8% smaller binary with my compiler. Only a single test case, not
a qualified survey.
c) No data.
d) No one seemed to have any substantial reasons why the ABI shouldn't
be changed. There were some concerns from Pablo Huerta, saying the ABI
change wouldn't be the best solution. Scott said the calling conventions
he's using for 64 bit values are more efficient than in the classic ABI.
Regards,
Heiko
_______________________________________________
http://www.opencores.org/mailman/listinfo/openrisc
>community. |
|||
|
Re: OpenRisc Digest, Vol 1, Issue 12
by Unknown on Dec 22, 2003 |
Not available! | ||
|
Heiko Panther wrote:
d) No one seemed to have any substantial reasons why the ABI
shouldn't be changed. There were some concerns from Pablo Huerta, saying the ABI change wouldn't be the best solution. Scott said the calling conventions he's using for 64 bit values are more efficient than in the classic ABI. In the existing 3.2 compiler, 64-bit values are passed to functions by reference. That is, the calling function must store the argument in two 32-bit words on the stack and pass that stack address to the callee. In the patch I submitted, 64-bit values are passed to callees as a register pair. This both saves execution time and stack space. I'm not sure the by-reference ABI was used, since the additional code to pass 64-bit values as register pairs is very tiny. -Scott |
|||
1/1