Re: EP9312 gcc: undefined reference to __divdf3

[Richard Earnshaw <rearnsha at gcc dot gnu dot org>]

On Fri, 2004-07-02 at 12:49, Vladimir Ivanov wrote:
> On Fri, 2 Jul 2004, Richard Earnshaw wrote:
> 
> > On Thu, 2004-07-01 at 19:26, Vladimir Ivanov wrote:
> > > On Thu, 1 Jul 2004, Richard Earnshaw wrote:
> > >
> > > > 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...

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

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

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