EP9312 gcc: undefined reference to __divdf3

[Wouter van Heyst]

Hello all,

I'm running into a problem trying to make a gcc 3.4.0 based toolchain
with MaverickCrunch support, during the final linkage of libc.so,
several functions turn up undefined references to __divdf3.

I think Richard Earnshaw and Vladimir Ivanov have spoken about this:
http://gcc.gnu.org/ml/gcc-patches/2004-03/msg00513.html

other than that thread I can't find a lot of references, neither is it
clear if Nucleusys have their copyright assignment yet, nor what the
current status is for the Cirrus ep9312 processor.

Anyway, trying to reproduce my problem I configured gcc seperately.
Multilib options in gcc/config/arm/t-arm-elf are uncommented per
http://gcc.gnu.org/gcc-3.4/changes.html:

MULTILIB_OPTIONS += mcpu=ep9312
MULTILIB_DIRNAMES += ep9312
MULTILIB_EXCEPTIONS += *mthumb/*mcpu=ep9312*

(no divdf3 mentioned in LIB1ASMFUNCS in that file, should it?)

Configured thusly:

../gcc-3.4.0/configure --target=arm-ep93xx-linux-gnu --host=powerpc-linux
--prefix=/opt/crosstool/arm-ep93xx-linux-gnu/gcc-3.4.0-glibc-2.3.2
--with-local-prefix=/opt/crosstool/arm-ep93xx-linux-gnu/gcc-3.4.0-glibc-2.3.2/arm-ep93xx-linu-gnu
--with-newlib --disable-nls --with-cpu=ep9312 --enable-threads=no
--enable-symvers=gnu --enable-__cxa_atexit --enable-languages=c
--disable-shared --enable-cxx-flags=-mcpu=ep9312

Followed by:
make all-gcc
make install-gcc

Results in a semi-working toolchain:

# cat test.c
int bar(float foo) {
float c = foo / 12.34;
}

int _start() {
bar(2);
}
# arm-ep93xx-linux-gnu-gcc test.c -nostdlib
/tmp/cc2t8YCe.o(.text+0x2c): In function `bar':
: undefined reference to `__divdf3'
collect2: ld returned 1 exit status


Assembly:
str r0, [fp, #-16] @ float
cfldrs mvf0, [fp, #-16]
cfcvtsd mvd0, mvf0
cfmvrdl r0, mvd0
cfmvrdh r1, mvd0
adr r2, .L2
ldmia r2, {r2-r3}
bl __divdf3
cfcvtds mvf0, mvd0
cfstrs mvf0, [fp, #-20]


Richard Earnshaw commented the divdf3 define_expand pattern might need
disabling, should I try that? I'm not well versed in gcc internals, but
I'm eager to tackle this. Pointers are greatly appreciated.

Of course, it's possible this is not a gcc bug, and I messed up,
pointing that out is welcome too :)

Wouter van Heyst

[Paul Koning]

Wouter> Hello all, I'm running into a problem trying to make a gcc
Wouter> 3.4.0 based toolchain with MaverickCrunch support, during the
Wouter> final linkage of libc.so, several functions turn up undefined
Wouter> references to __divdf3.

I just reported that the other day, and it was fixed for 3.4.1.
See http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16144 for details.

paul

[Wouter van Heyst]

Post by Paul Koning
Wouter> Hello all, I'm running into a problem trying to make a gcc
Wouter> 3.4.0 based toolchain with MaverickCrunch support, during the
Wouter> final linkage of libc.so, several functions turn up undefined
Wouter> references to __divdf3.
I just reported that the other day, and it was fixed for 3.4.1.
See http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16144 for details.

Ah, I should have mentioned the ep9312 is an ARM processor. The mips.md
commit won't do me much good, but perhaps I can steal the technique,
thanks!

*runs off to fiddle with arm.md*

Wouter van Heyst

[Richard Earnshaw]

Post by Wouter van Heyst
Hello all,
I'm running into a problem trying to make a gcc 3.4.0 based toolchain
with MaverickCrunch support, during the final linkage of libc.so,
several functions turn up undefined references to __divdf3.

This is a bug and you should file it in our bugzilla database:

http://gcc.gnu.org/bugzilla

The problem is that the FPU on this chip does not have a floating point
divide instruction, so we need to provide one in software. The library
function that we have (in config/arm/ieee754-df.c) returns values in
integer registers, but in the configuration you have the compiler would
expect it to be returned in an FP register; so at this point in time
there is no benefit to be gained from making it call the library
function directly.

The best solution would be to tell the compiler that all floating point
compiler support functions return values in integer registers, but
before we can do that we have to re-implement a couple of support calls
that are currently coded in C (and thus use normal register passing
conventions).

The solution is complex enough that I suspect that it's unlikely that
this will be fixed in the gcc 3.4 series, since this is not a
regression.

R.

[Wouter van Heyst]

Post by Paul Koning

Post by Wouter van Heyst
Hello all,
I'm running into a problem trying to make a gcc 3.4.0 based toolchain
with MaverickCrunch support, during the final linkage of libc.so,
several functions turn up undefined references to __divdf3.

http://gcc.gnu.org/bugzilla
The problem is that the FPU on this chip does not have a floating point
divide instruction, so we need to provide one in software. The library
function that we have (in config/arm/ieee754-df.c) returns values in
integer registers, but in the configuration you have the compiler would
expect it to be returned in an FP register; so at this point in time
there is no benefit to be gained from making it call the library
function directly.

Nasty. I completely overlooked the fact there is no floating point
divide instruction, but looking at the ep9312 user guide I'm afraid
you're right, sigh. Would another configuration give integer register
passing _and_ MaverickCrunch support?

Post by Paul Koning
The best solution would be to tell the compiler that all floating point
compiler support functions return values in integer registers, but
before we can do that we have to re-implement a couple of support calls
that are currently coded in C (and thus use normal register passing
conventions).

How do you determine what support calls need to be reimplemented?

Post by Paul Koning
The solution is complex enough that I suspect that it's unlikely that
this will be fixed in the gcc 3.4 series, since this is not a
regression.

Yesterday drow and pbrook on #gcc suggested I try csl-arm-branch, using
that instead of gcc-3.4.0 but configure/test the same way, there is no
undefined reference. Unfortunately, there is also no Crunch assembly
anymore, bummer.

Since it's more than just an undefined reference, how do you suggest the
bug be worded? Something like "floating point support function should
return values in integer registers"?

Not having this fixed in 3.4 isn't that big a problem for me, getting a
working situation reasonably soonish is more important. From your
explanation above I have a vague idea what needs to be done, but none at
all on how to do it. More reading of code coming up for me I suppose.

Wouter van Heyst

[Wouter van Heyst]

On Wed, Jun 30, 2004 at 12:54:31PM +0200, Wouter van Heyst wrote:

<snip>

Post by Wouter van Heyst
Yesterday drow and pbrook on #gcc suggested I try csl-arm-branch, using
that instead of gcc-3.4.0 but configure/test the same way, there is no
undefined reference. Unfortunately, there is also no Crunch assembly
anymore, bummer.

Ahum, that isn't exactly true. On the csl-arm-branch, --with-cpu=ep9312
no longer implies --with-fpu=maverick. Also, forgetting to turn on the
ep9312 multilib doesn't help *blush*.

Now it doees generate Crunch assembly, but the undefined reference to
__divdf3 is back.

Wouter van Heyst

[Richard Earnshaw]

Post by Wouter van Heyst
Would another configuration give integer register
passing _and_ MaverickCrunch support?

I'm not aware of one.

Post by Wouter van Heyst

Post by Richard Earnshaw
The best solution would be to tell the compiler that all floating point
compiler support functions return values in integer registers, but
before we can do that we have to re-implement a couple of support calls
that are currently coded in C (and thus use normal register passing
conventions).

How do you determine what support calls need to be reimplemented?

Internal knowledge of the functions and what they do; plus some testing
:-)

Post by Wouter van Heyst
Since it's more than just an undefined reference, how do you suggest the
bug be worded? Something like "floating point support function should
return values in integer registers"?

No need to go that far. Just make the subject exactly the same as your
subject line above. Set the target to arm-elf. And provide a small
test case -- that's easy, something like

double x, y; float a, b;

int main () { a = a/b; x = x /y; exit 0;}

should amply demonstrate the problem.

R.

[Wouter van Heyst]

Post by Paul Koning

Post by Wouter van Heyst
Hello all,
I'm running into a problem trying to make a gcc 3.4.0 based toolchain
with MaverickCrunch support, during the final linkage of libc.so,
several functions turn up undefined references to __divdf3.

http://gcc.gnu.org/bugzilla

Waiting for my account details to be mailed, I'll file it later today.

Post by Paul Koning
The problem is that the FPU on this chip does not have a floating point
divide instruction, so we need to provide one in software. The library
function that we have (in config/arm/ieee754-df.c) returns values in
integer registers, but in the configuration you have the compiler would
expect it to be returned in an FP register; so at this point in time
there is no benefit to be gained from making it call the library
function directly.

So that's close to variant 8 (-mfpu=maverick -mfloat-abi=soft+fp) from [1],
except several of the hardware instructions will have to be done in
software too. Am I right that this form of variant 8 will be ABI
compatible with other -mfloat-abi=soft+fp and -mfloat-abi=soft binaries,
but also have hardware support in function bodies for the fpu of my
choice? If so, that would be the optimal situation.

1. http://gcc.gnu.org/ml/gcc-patches/2003-12/msg00642.html

Wouter van Heyst

[Paul Brook]

Post by Wouter van Heyst

Post by Richard Earnshaw
The problem is that the FPU on this chip does not have a floating point
divide instruction, so we need to provide one in software. The library
function that we have (in config/arm/ieee754-df.c) returns values in
integer registers, but in the configuration you have the compiler would
expect it to be returned in an FP register; so at this point in time
there is no benefit to be gained from making it call the library
function directly.

So that's close to variant 8 (-mfpu=maverick -mfloat-abi=soft+fp) from [1],
except several of the hardware instructions will have to be done in
software too.

Yes, variant 8 should 'just work', except that it isn't implemented in the
compiler :)

To get full hardware float (variant 9) you need to modify the support routines
for unimplemented instructions (eg. div) to return values in hardware
registers.

N.B. The current maverick ABI is based on the legacy fpa ABI, and passes
floating point values in integer registers.
I think someone mentioned they were changing the ABI anyway. If so it's
probably worth fixing this to pass arguments in fp regs at the same time.

Post by Wouter van Heyst
Am I right that this form of variant 8 will be ABI
compatible with other -mfloat-abi=soft+fp and -mfloat-abi=soft binaries,
but also have hardware support in function bodies for the fpu of my
choice? If so, that would be the optimal situation.

There are two issues that determine binary compatability: The ABI used for
passing/returning floating point function arguments (-mfloat-abi=), and the
floating point format used (-mfpu=).

The maverick coprocessor uses a different floating point format the fpa
coprocessor (the linux default), so is never going to be comapatible.

For a given floating point format, the soft and soft+fp options use the same
ABI.

In general the different floating point format are not binary compatible with
each other. While all they all use IEEE format, they use differing byte
endianness. Thus variant 8 is not binary compatible with variants 5 or 6.

Paul

Post by Wouter van Heyst
1. http://gcc.gnu.org/ml/gcc-patches/2003-12/msg00642.html

[Richard Earnshaw]

Post by Paul Brook
N.B. The current maverick ABI is based on the legacy fpa ABI, and passes
floating point values in integer registers.
I think someone mentioned they were changing the ABI anyway. If so it's
probably worth fixing this to pass arguments in fp regs at the same time.

I agree. In fact, it would be extremely useful if somebody could write
a co-processor supplement to the AAPCS for Maverick. Such a document
would have to cover the following sections of the main document[1]:

- A statement equivalent to section 5.1.1.1 concerning Maverick
registers.

- A section equivalent to 6.1 (and all its subsections)
documenting when results are not returned in core registers and
which arguments to function calls should be considered for
passing in registers other than core registers.

Ideally the supplement should also document the compatibility of the
variant with the various other variants that exist, equivalent to those
statements in section 6.3.

It's not a big task, probably only a couple of sides of A4 based on the
equivalent information for the VFP co-processor.

Note that the existing calling convention *could* be written up in this
way, but I'm not sure that would really want to adopt this calling
convention -- it's very inefficient if you have floating point registers
to keep moving the values back to core registers, and there's no merit
of compatibility with the soft-call standard when the result values can
come back in a non-standard register.

R.

[Richard Earnshaw]

Post by Richard Earnshaw

Post by Paul Brook
N.B. The current maverick ABI is based on the legacy fpa ABI, and passes
floating point values in integer registers.
I think someone mentioned they were changing the ABI anyway. If so it's
probably worth fixing this to pass arguments in fp regs at the same time.

I agree. In fact, it would be extremely useful if somebody could write
a co-processor supplement to the AAPCS for Maverick. Such a document
- A statement equivalent to section 5.1.1.1 concerning Maverick
registers.
- A section equivalent to 6.1 (and all its subsections)
documenting when results are not returned in core registers and
which arguments to function calls should be considered for
passing in registers other than core registers.
Ideally the supplement should also document the compatibility of the
variant with the various other variants that exist, equivalent to those
statements in section 6.3.
It's not a big task, probably only a couple of sides of A4 based on the
equivalent information for the VFP co-processor.
Note that the existing calling convention *could* be written up in this
way, but I'm not sure that would really want to adopt this calling
convention -- it's very inefficient if you have floating point registers
to keep moving the values back to core registers, and there's no merit
of compatibility with the soft-call standard when the result values can
come back in a non-standard register.
R.

Argh! I forgot to provide the link to the AAPCS :-(

[1] http://www.arm.com/products/DevTools/abi/aapcs.pdf

R.

[Vladimir Ivanov]

Post by Richard Earnshaw

Post by Paul Brook
N.B. The current maverick ABI is based on the legacy fpa ABI, and passes
floating point values in integer registers.
I think someone mentioned they were changing the ABI anyway. If so it's
probably worth fixing this to pass arguments in fp regs at the same time.

I agree. In fact, it would be extremely useful if somebody could write
a co-processor supplement to the AAPCS for Maverick. Such a document
- A statement equivalent to section 5.1.1.1 concerning Maverick
registers.
- A section equivalent to 6.1 (and all its subsections)
documenting when results are not returned in core registers and
which arguments to function calls should be considered for
passing in registers other than core registers.
Ideally the supplement should also document the compatibility of the
variant with the various other variants that exist, equivalent to those
statements in section 6.3.
It's not a big task, probably only a couple of sides of A4 based on the
equivalent information for the VFP co-processor.

We can do this. Do you have any template for this document?
Contact me in case we can help.

Post by Richard Earnshaw
Note that the existing calling convention *could* be written up in this
way, but I'm not sure that would really want to adopt this calling
convention -- it's very inefficient if you have floating point registers
to keep moving the values back to core registers, and there's no merit
of compatibility with the soft-call standard when the result values can
come back in a non-standard register.

I agree that it is quite strange, but it is adopted from FPA and is the
de-facto ABI for GCC-3.4. If the various ABI variants for VFP are already
implemented in GCC mainline, porting them to MaverickCrunch seems
reasonable task.

And with some luck, the patch to do this could be small enough so we won't
need (that so hard to obtain) assignment again. :-)

-- vladitx

[Richard Earnshaw]

Post by Vladimir Ivanov

Post by Richard Earnshaw

Post by Paul Brook
N.B. The current maverick ABI is based on the legacy fpa ABI, and passes
floating point values in integer registers.
I think someone mentioned they were changing the ABI anyway. If so it's
probably worth fixing this to pass arguments in fp regs at the same time.

I agree. In fact, it would be extremely useful if somebody could write
a co-processor supplement to the AAPCS for Maverick. Such a document
- A statement equivalent to section 5.1.1.1 concerning Maverick
registers.
- A section equivalent to 6.1 (and all its subsections)
documenting when results are not returned in core registers and
which arguments to function calls should be considered for
passing in registers other than core registers.
Ideally the supplement should also document the compatibility of the
variant with the various other variants that exist, equivalent to those
statements in section 6.3.
It's not a big task, probably only a couple of sides of A4 based on the
equivalent information for the VFP co-processor.

We can do this. Do you have any template for this document?
Contact me in case we can help.

Not as a standalone document, the VFP is the only co-processor we've
produced this information for so far and that's recored as part of the
AAPCS document itself. However, I've tried to keep the material
relating to the VFP as distinct sections even then.

So your best starting point would be to look at the sections I've
outlined in the AAPCS and to replicate them with appropriate changes
made for the Maverick.

http://www.arm.com/products/DevTools/abi/aapcs.pdf

Post by Vladimir Ivanov

Post by Richard Earnshaw
Note that the existing calling convention *could* be written up in this
way, but I'm not sure that would really want to adopt this calling
convention -- it's very inefficient if you have floating point registers
to keep moving the values back to core registers, and there's no merit
of compatibility with the soft-call standard when the result values can
come back in a non-standard register.

I agree that it is quite strange, but it is adopted from FPA and is the
de-facto ABI for GCC-3.4. If the various ABI variants for VFP are already
implemented in GCC mainline, porting them to MaverickCrunch seems
reasonable task.

The FPA calling model as implemented by GCC goes back into pre-history
and was implemented that way because that's what the ABI of RISC iX used
(the first ARM port of GCC was to RISC iX). History, however, suggests
that was a poor design choice and we don't want to perpetuate that
mistake any longer than necessary.

There's no support for using VFP registers for argument passing in GCC
yet, though that's certainly on the to-do list somewhere. And yes, if
the rules are similar enough it shouldn't be a major task to support
Maverick as well.

R.

[Vladimir Ivanov]

Post by Richard Earnshaw

Post by Vladimir Ivanov

Post by Richard Earnshaw
It's not a big task, probably only a couple of sides of A4 based on the
equivalent information for the VFP co-processor.

We can do this. Do you have any template for this document?
Contact me in case we can help.

Not as a standalone document, the VFP is the only co-processor we've
produced this information for so far and that's recored as part of the
AAPCS document itself. However, I've tried to keep the material
relating to the VFP as distinct sections even then.

Do you want the MaverickCrunch variant of these chapters in plain-text,
or you have some high-level (text-editor friendly) source available which
I could use?

Post by Richard Earnshaw
So your best starting point would be to look at the sections I've
outlined in the AAPCS and to replicate them with appropriate changes
made for the Maverick.
http://www.arm.com/products/DevTools/abi/aapcs.pdf

I examined the sections - certainly not a big deal to replicate them for
MaverickCrunch. The only question that arises is where the split between
argument/scratch and callee-saved registers should be - in GCC 3.4.x it is
mv0..mv3 for arguments/scratch and mv4..mv15 for callee-save. That could
be just another FPA legacy during the time of the initial port, and with
regard to VFP it should be more like mv0..mv7 vs. mv8..mv15. On the other
side, VFP allows for return of up-to four floating-point values, so still
mv0..m3 vs. mv4..mv15 looks good solution. I don't know how that relates
to performance, though.

Any suggestions?

Post by Richard Earnshaw
The FPA calling model as implemented by GCC goes back into pre-history
and was implemented that way because that's what the ABI of RISC iX used
(the first ARM port of GCC was to RISC iX). History, however, suggests
that was a poor design choice and we don't want to perpetuate that
mistake any longer than necessary.

As MaverickCrunch ABI in GCC 3.4.x is FPA-alike, do you plan to keep it in
GCC 3.5+ with special option or just deprecate it?

Post by Richard Earnshaw
There's no support for using VFP registers for argument passing in GCC
yet, though that's certainly on the to-do list somewhere. And yes, if
the rules are similar enough it shouldn't be a major task to support
Maverick as well.

It would be a good thing if someone informs me when VFP has this
implemented, so I could port it for MaverickCrunch as well. I am not a GCC
wizard, so a prior art is mostly welcome.

-- vladitx

[Richard Earnshaw]

Post by Vladimir Ivanov

Post by Richard Earnshaw

Post by Vladimir Ivanov

Post by Richard Earnshaw
It's not a big task, probably only a couple of sides of A4 based on the
equivalent information for the VFP co-processor.

We can do this. Do you have any template for this document?
Contact me in case we can help.

Not as a standalone document, the VFP is the only co-processor we've
produced this information for so far and that's recored as part of the
AAPCS document itself. However, I've tried to keep the material
relating to the VFP as distinct sections even then.

Do you want the MaverickCrunch variant of these chapters in plain-text,
or you have some high-level (text-editor friendly) source available which
I could use?

How you write the document is up to you. In terms of its publication
the best bet would be for Cirrus to publish it on their own web site
along with the other Maverick documentation. I'll ensure that future
revisions of the AAPCS note that vendor co-processors can have ABI
variants that are documented elsewhere and to suggest that the
manufacturer's web sites should be checked.

It might be possible to get a link from the ABI pages on our web site to
the appropriate pages on other sites, but I can't make any promises in
that area -- there's a marketing angle that has to be considered too...

Post by Vladimir Ivanov

Post by Richard Earnshaw
So your best starting point would be to look at the sections I've
outlined in the AAPCS and to replicate them with appropriate changes
made for the Maverick.
http://www.arm.com/products/DevTools/abi/aapcs.pdf

I examined the sections - certainly not a big deal to replicate them for
MaverickCrunch. The only question that arises is where the split between
argument/scratch and callee-saved registers should be - in GCC 3.4.x it is
mv0..mv3 for arguments/scratch and mv4..mv15 for callee-save. That could
be just another FPA legacy during the time of the initial port, and with
regard to VFP it should be more like mv0..mv7 vs. mv8..mv15. On the other
side, VFP allows for return of up-to four floating-point values, so still
mv0..m3 vs. mv4..mv15 looks good solution. I don't know how that relates
to performance, though.
Any suggestions?

There is a trend these days towards caller-save registers, this is
especially true if there are no store-multiple instructions.
Caller-save is also cheaper to implement in setjmp and exception
unwinding (there's nothing to do in either case!).

On top of this you also want to consider what a typical subroutine call
using FP arguments might want to pass. Code doing 3d graphics might
well want to pass 2 4-element vectors so being able to pass all the
values in registers might be a big win.

Given all the above, my inclination would be to make mv0-mv7
caller-save/argument registers and to make mv8-mv15 callee-saved. The
72-bit accumulator registers should all be caller-saved. The assumption
here is that these are generally scratch registers, or used only in leaf
functions.

Post by Vladimir Ivanov

Post by Richard Earnshaw
The FPA calling model as implemented by GCC goes back into pre-history
and was implemented that way because that's what the ABI of RISC iX used
(the first ARM port of GCC was to RISC iX). History, however, suggests
that was a poor design choice and we don't want to perpetuate that
mistake any longer than necessary.

As MaverickCrunch ABI in GCC 3.4.x is FPA-alike, do you plan to keep it in
GCC 3.5+ with special option or just deprecate it?

That's essentially up to the user base. If that is zero, then we can
just delete it. If it's substantial then the old ABI may have to
persist for a while -- given the number of outstanding issues on the
port, my guess is that the answer lies nearer to the former than to the
latter, so it may be necessary only to keep the old ABI around for about
one release (and even then not as the default). From a personal
perspective, old ABIs cause a maintenance/testing nightmare, the sooner
they can go away the better for everyone.

Post by Vladimir Ivanov

Post by Richard Earnshaw
There's no support for using VFP registers for argument passing in GCC
yet, though that's certainly on the to-do list somewhere. And yes, if
the rules are similar enough it shouldn't be a major task to support
Maverick as well.

It would be a good thing if someone informs me when VFP has this
implemented, so I could port it for MaverickCrunch as well. I am not a GCC
wizard, so a prior art is mostly welcome.

OK. I'll try and remember.

R.

[Richard Earnshaw]

Post by Wouter van Heyst

Post by Richard Earnshaw
The problem is that the FPU on this chip does not have a floating point
divide instruction, so we need to provide one in software. The library
function that we have (in config/arm/ieee754-df.c) returns values in
integer registers, but in the configuration you have the compiler would
expect it to be returned in an FP register; so at this point in time
there is no benefit to be gained from making it call the library
function directly.

So that's close to variant 8 (-mfpu=maverick -mfloat-abi=soft+fp) from [1],
except several of the hardware instructions will have to be done in
software too. Am I right that this form of variant 8 will be ABI
compatible with other -mfloat-abi=soft+fp and -mfloat-abi=soft binaries,
but also have hardware support in function bodies for the fpu of my
choice? If so, that would be the optimal situation.
1. http://gcc.gnu.org/ml/gcc-patches/2003-12/msg00642.html

Substantially yes -- note that that email was a design sketch, it may
not be exactly what was implemented in GCC, but it does give the right
split of the various permutations.

You should also look at the various EABI specifications,

http://www.arm.com/products/DevTools/ABI.html

specifically, at these two:

http://www.arm.com/products/DevTools/abi/aapcs.pdf
http://www.arm.com/products/DevTools/abi/rtabi.pdf

It's not explicit in that document, but the intention is that,
regardless of the calling convention in use for 'user' code, all support
functions should be implemented using the base-standard calling
convention (this provides for a modicum of Thumb interworking). That's
substantially variants 8 and 9 in the email I posted previously.

R.

[Petko Manolov]

Sorry, i am not subscribed to the list so i had to copy the message body
from the browser.

Post by Wouter van Heyst
Would another configuration give integer register
passing _and_ MaverickCrunch support?

In our implementation functions with FP arguments pass them through the
ARM registers (r0-r1, r2-r3, stack) and return in mvd0. FPA code is doing
the same thing.

Post by Wouter van Heyst

The best solution would be to tell the compiler that all floating point
compiler support functions return values in integer registers, but
before we can do that we have to re-implement a couple of support calls
that are currently coded in C (and thus use normal register passing
conventions).

How do you determine what support calls need to be reimplemented?

We followed the convention used in gcc-3.4.0 for HW floating point. AFAIK
this is going to change (or it is in a process of changing) in gcc-3.5.
If i am not mistaken FP arguments should be supplied through integer
registers, the result goes in r0 if float and r0-r1 if double.


Petko

[Vladimir Ivanov]

Post by Wouter van Heyst
Hello all,
I'm running into a problem trying to make a gcc 3.4.0 based toolchain
with MaverickCrunch support, during the final linkage of libc.so,
several functions turn up undefined references to __divdf3.

You're missing the soft-float division since the MaverickCrunch
coprocessor lacks such instruction. You can do this by using the good work
of Nicolas Pitre:
gcc/config/arm/ieee-754-[sd]f.c

You also have to modify it so the return value is passed through mv0.
Multilibs is a nice solution.

Post by Wouter van Heyst
http://gcc.gnu.org/ml/gcc-patches/2004-03/msg00513.html
other than that thread I can't find a lot of references, neither is it
clear if Nucleusys have their copyright assignment yet, nor what the
current status is for the Cirrus ep9312 processor.

Nope, we still don't have that copyright assignment, even after three
attempts so far.

As to the current status of EP9312 support in 3.4.x - it is a good work by
Aldy Hernandez, but unfortunatelly kind of unfinished:
- it lacks prologue/epilogue register save, so function calls get funny
- it doesn't have proper workarounds for the errata of the current chips
on the market

Also, to have working programs for Linux you need also some changes to
GLIBC. Notice that using shared libraries is *not* possible, unless you
build all your libraries with Crunch support, since the API is different
from the arm-linux default (FPA).

Post by Wouter van Heyst
MULTILIB_OPTIONS += mcpu=ep9312
MULTILIB_DIRNAMES += ep9312
MULTILIB_EXCEPTIONS += *mthumb/*mcpu=ep9312*
(no divdf3 mentioned in LIB1ASMFUNCS in that file, should it?)

Take a look at "t-arm-elf" for example how to include "divdf3".

Post by Wouter van Heyst
Richard Earnshaw commented the divdf3 define_expand pattern might need
disabling, should I try that?

I don't know, but we have it working without disabling.
I also think that once I tried disabling it and it led to another problem,
but right now I'm not sure what exactly.

Cheers,
-- vladitx

[Paul Brook]

Post by Vladimir Ivanov

Post by Wouter van Heyst
Richard Earnshaw commented the divdf3 define_expand pattern might need
disabling, should I try that?

I don't know, but we have it working without disabling.
I also think that once I tried disabling it and it led to another problem,
but right now I'm not sure what exactly.

The divdf3 and divsf3 patterns are already disabled when generating maverick
code.

Paul

[Vladimir Ivanov]

Post by Paul Brook

Post by Vladimir Ivanov

Post by Wouter van Heyst
Richard Earnshaw commented the divdf3 define_expand pattern might need
disabling, should I try that?

I don't know, but we have it working without disabling.
I also think that once I tried disabling it and it led to another problem,
but right now I'm not sure what exactly.

The divdf3 and divsf3 patterns are already disabled when generating maverick
code.

Right - that's why the library call. :-)
Must have been something else that Richard suggested and I've tried ...

-- vladitx