This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: EP9312 gcc: undefined reference to __divdf3

On Thu, 1 Jul 2004, Richard Earnshaw wrote:

> On Thu, 2004-07-01 at 11:53, Paul Brook wrote:
> > 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 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.

> 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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]