* Scott Furman (sfurman@rosum.com) wrote:

Hi Scott,

i've patched the oc gcc-3.1 and it aplied cleanly. i tried to compile
it but compilation failed, due to some poisoned defines... did you
just remove it from poison list in gcc/system.h ?

best regards,
p.

patch applied cleanly:
patching file gcc/config/or32/or32.c
patching file gcc/config/or32/or32.h
patching file gcc/config/or32/or32.md

compile:
gcc -c -DIN_GCC -DHAVE_CONFIG_H -DIN_GCC -DCROSS_COMPILE -g -O2 -W -Wall
-Wwrite-strings -Wstrict-prototy
pes -Wmissing-prototypes -Wtraditional -pedantic -Wno-long-long
-DHAVE_CONFIG_H -DGENERATOR_FILE -W -Wal
l -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wtraditional
-pedantic
-Wno-long-long -I. -I.
. -I/center/opencores/toolchains/oc-1.4/p_root/gcc-3.1/gcc/fixinc
-I/center/opencores/toolchains/oc-1.4/p
_root/gcc-3.1/gcc/fixinc/..
-I/center/opencores/toolchains/oc-1.4/p_root/gcc-3.1/gcc/fixinc/../config -I/
center/opencores/toolchains/oc-1.4/p_root/gcc-3.1/gcc/fixinc/../../include
/center/opencores/toolchains/o
c-1.4/p_root/gcc-3.1/gcc/fixinc/server.c
In file included from ../config.h:18,
from
/center/opencores/toolchains/oc-1.4/p_root/gcc-3.1/gcc/fixinc/fixlib.h:30,
from
/center/opencores/toolchains/oc-1.4/p_root/gcc-3.1/gcc/fixinc/server.h:57,
from
/center/opencores/toolchains/oc-1.4/p_root/gcc-3.1/gcc/fixinc/server.c:54:
/center/opencores/toolchains/oc-1.4/p_root/gcc-3.1/gcc/config/or32/or32.h:774:9
attempt to use
poisoned
"IMPLICIT_FIX_EXPR"
/center/opencores/toolchains/oc-1.4/p_root/gcc-3.1/gcc/config/or32/or32.h:777:9
attempt to use
poisoned
"EASY_DIV_EXPR"
/center/opencores/toolchains/oc-1.4/p_root/gcc-3.1/gcc/config/or32/or32.h:1194:
attempt to use poisoned
"ASM_OPEN_PAREN"

/center/opencores/toolchains/oc-1.4/p_root/gcc-3.1/gcc/config/or32/or32.h:1195:
attempt to use poisoned
"ASM_CLOSE_PAREN"
make[2]: *** [server.o] Error 1
make[2]: Leaving directory
/center/opencores/toolchains/oc-1.4/p_root/b-gcc-3.1/gcc/fixinc'
make[1]: *** [fixinc.sh] Error 2
make[1]: Leaving directory
/center/opencores/toolchains/oc-1.4/p_root/b-gcc-3.1/gcc'
make: *** [all-gcc] Error 2

* Matjaz Breskvar (phoenix@opencores.org) wrote:

Regarding different ABI versions:

I was not aware there were two official ABIs (old and new) around at
all. So if Scott says UC-gcc-3.4 uses the outdated ABI, then my 3.2.3
does too.

Matjaz, you proposed to go back to gcc-3.1 if it works with everything,
and go to newer gcc versions from there. I agree with that.

I examined the crash Matjaz reported with uclinux and gcc-2.3.2. Looks
like it will take some serious amount of gcc debugging to locate the
problem. I won't do that, since it seems likely that the version will be
abandoned anyway.

Heiko

All,

there are no new and old ABI, just some differences between different
implementations. This is due to chicken and egg problem. Originally the ABI
was set in the arch manual as a starting point and it would be updated once
we find out which ABI works best. This kind of got out of control because
people starting doing different compiler branches and everybody was making
their own changes locally... Anyway I'm attaching ABI chapter from the arch
manual (updated with soem changes, see below). Since today we already have
eCos and uClinux&Linux running, maybe it is finally time to have arch manual
updated once and for all (so that the guys that will port Windows will know
which ABI to use ;-)

I have attached RTF. I hope everybody can read RTF. If not let me know (but
if I send plain text file I will have more work merging everything back to
the original document and please don't propose to go and change the format
of the original arch manual ;-) Anyway the changes implemented in this ABI
chapter compared to the arch manual in the cvs are the following:
- changed callee saved registers (swapped temp registers and callee saved
according to
/* 1 for registers not available across function calls.
These must include the FIXED_REGISTERS and also any
registers that can be used without being saved.
The latter must include the registers where values are returned
and the register where structure-value addresses are passed.
Aside from that, you can include as many other registers as you like.
*/
#define CALL_USED_REGISTERS {1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 0, 1, 0, 1, 0,
1 \
, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0,
1}
- added RVH
- added that 64-bit values can be passed in pair of registers on 32-bit
system (see comment in the file should registers of a pair be aligned or
not)

*** Please everybody (at least all those that are doing your own compilers
;-) read the the RTF file and provide feedback. Even more preferred would be
that you directly change the document however since this is RTF file and
changes can be only merged manually (not with cvs) we can change the
document only if we do it in round robin fashion (one by one eaching sending
the document back to the list). *** Also everything else that is missing in
the ABI should be added at this point. Anything missing?? ***

regards,
Damjan

----- Original Message -----
From: "Heiko Panther"
To:
Sent: Wednesday, January 28, 2004 12:50 PM
Subject: Re: [openrisc] gcc-3.2.3 bugs after merge


-------------- next part -------------- A non-text attachment was scrubbed... Name: openrisc_abi_chapter.rtf Type: application/msword Size: 305233 bytes Desc: not available Url : http://www.opencores.org/forums/openrisc/attachments/20040128/d5838e6b/openrisc_abi_chapter-0001.dot

* Damjan Lampret (lampret@opencores.org) wrote:

Scott,

I think we're going to proceed with your ABI & corrections. Could you
please describe your convention (ABI) for 64bit values. Thank you.

Since there's been no replies i guess everybody is happy with it.

best regards,
p.

Can we sort out the ABI thing before this Saturday. I'd like to freshen up the FP support in GCC and or1ksim and add it to the or1200. Because I only want to do the GCC once, I don't want update the GCC again if somebody goes and modifies the gcc's or32.h/md files... This brings up the question which GCC should I use to freshen the FP support. I'm thinking to use OC GCC-3.2.3. I'm planning to do the FP support on Saturday. Heiko same for debug. Can we finalize debug arch spec by Saturday so I can finish all the work on OR1200 RTL. regards, Damjan ----- Original Message ----- From: "Matjaz Breskvar" phoenix@opencores.org> To: "List about OpenRISC project" openrisc@opencores.org> Sent: Wednesday, February 04, 2004 3:48 AM Subject: Re: [openrisc] gcc-3.2.3 bugs after merge

Matjaz Breskvar wrote:


Does this mean that you got all the eCos tests, linux, etc. working with
the 3.1 compiler ? (Last I recall, you had positive results, but needed
to increase the timeout for some tests.)

-Scott

Matjaz Breskvar wrote:

First, let me describe the ABI as it is currently implemented in the gcc 3.1 patch that I sent you recently. In a separate follow-up message, I'll comment on the ABI changes suggested by Damjan (but not implemented yet). The new ABI is the same as the ABI implemented by the existing OR gcc 3.1, with these exceptions: 1. 64-bit scalar values (long long and double) are passed in by value instead of by reference. The high 32 bits of an argument are always passed in an even register and the low 32 bits is passed in the next highest even register. As a result of this register alignment, there may be "holes" in the register list used to pass arguments. For example, this function: int func(double arg1, int arg2); would pass the low 32 bits of 'arg1' in R4 and the high 32 bits of 'arg1' in R5. 'arg2' would be passed in R6 and R3 would not be used. 2. Aggregate and 64-bit scalar return values are handled by passing a "hidden" first argument to the function (in R3) that contains the address of the return value, e.g. on the caller's stack. (Unlike the existing PCC-style struct return approach used by OR gcc 3.1, this approach is thread-safe.) The return value of a function with a struct return value is the address of the struct, i.e. same as the value of the hidden argument. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.opencores.org/forums/openrisc/attachments/20040204/e802c969/attachment.htm

Here are some responses to Damjan's ABI proposal:

Damjan wrote:


The patch I submitted for OR gcc 3.1 uses aligned register pairs to
contain 64-bit scalars. However, I can think of no good reason for this
alignment. (There aren't any instructions that operate on register
pairs, are there ? ) It's better to not require any specific alignment
and, hence, improve argument packing. I suggest that we make the modest
change to the gcc port required.



There are a couple of potential issues with this suggestion:

* In the old ABI, R12 was previously a callee-saved register and in
the proposed ABI it may be clobbered by a callee. If we adopt
this convention, we'll need to scour all the hand-written assembly
code for failure to preserve R12 across function calls.
* I don't know how to make gcc use R12 as a temporary when it's not
being used as RVH (which is the common case). Probably, gcc will
do this automatically if RVH is not used, but I haven't tried, so
I don't know how easy this will be to implement.

In section 1.2.2, in the illustration depicting stack layout, you wrote
the following about stack locations SP-4 ->SP-2096:



In general, it is never safe to access memory locations below SP, leaf
function or not, since that part of the stack may get clobbered by
interrupt handlers. (It's only safe to do that if interrupts are disabled.)

Also, you may want to show "outgoing arguments" in this same illust.

Such a function should also accept the address of the aggregate as a "hidden" first argument. -Scott -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.opencores.org/forums/openrisc/attachments/20040204/fb4a0602/attachment.htm

* Scott Furman (sfurman@rosum.com) wrote: let me sumrize: - as far as i can tell 2 ecos test fail (attached). this is WAY better than with any other compiler (i couldn't even run twothreads demo with others). now i'm not sure i have the right (most current) ecos version, so i'd really just remove the old ecos from CVS and add a current one. I can import what i got and you can diff it towards your version (to check that we are in sync) or you can just import your version, whatever you prefer. - linux compiles as good as with gcc-3.2.3 without your corrections, (i'm using it as a default compiler since and it works great). there is still one issue (somewhere in the toolchain) with passing gcc attributes (for placing some function into specific section). i'm currently debugging it but it is the same problem as with any other toolchain. what i did is also to merge your stuff into gcc-3.2.3 tree. tried that on linux and it works ok. i also did a quick run through ecos tests and it looks ok. i'm running now with tests with 50 milion intsructions for each test. it will take some time to finish though i tried ~15 toolchain combinations with linux & ecos and i can tell that your patches for binutils & gcc are big improvment (and don't break anything new). since nobody else showed any interest in fixing other compiler version i say we go with this one that works the best. best regards, p. -------------- next part -------------- A non-text attachment was scrubbed... Name: ecos-failed.tar.gz Type: application/x-gzip Size: 822 bytes Desc: not available Url : http://www.opencores.org/forums/openrisc/attachments/20040205/9032a5b3/ecos-failed.tar.bin

* Scott Furman (sfurman@rosum.com) wrote:

is there any special reason that we need these 'register aligment' ?

best regards,
p.

* Matjaz Breskvar (phoenix@opencores.org) wrote:

it turned out not to be a compiler but kernel bug (fixed now). i
also removed all my workarounds for gcc/binutils bugs and linux boots,
so this is indeed an improvments. more on linux in next email...

regards,
p.

I would like to see all patches etc. be put into 3.2.3 as well as 3.1 and then put into CVS and tagged. Then perhaps a combined effort could get to the bottom of the problems seen with eCos. I have no objections to the ABI changes at all. I have not been contributing much as the version of 3.2.3 I'm using (which contains all the patches submitted by Scott and Heiko, I think), along with GDB 5.3 works OK for what I want at the moment. I'm using eCos but only the minimal configuration, i.e. no Kernel, so I am really using it only for infrastructure and GDB stubs support currently. Robert Cragie, Design Engineer _______________________________________________________________ Jennic Ltd, Furnival Street, Sheffield, S1 4QT, UK http://www.jennic.com Tel: +44 (0) 114 281 2655 _______________________________________________________________