RE: Introducing a nanoMIPS port for Binutils, GDB and GOLD

[Matthew Fortune <Matthew dot Fortune at mips dot com>]

Joseph Myers <joseph@codesourcery.com> writes:
> On Tue, 1 May 2018, Matthew Fortune wrote:
> 
> > [2] Codescape GNU tools for nanoMIPS: ELF ABI Supplement,
> >
> > https://codescape.mips.com/components/toolchain/nanomips/2018.04-02/do
> > cs/MIPS_nanoMIPS_ABI_supplement_01_02_DN00179.pdf

Hi Joseph,

Thanks for the speedy feedback. It would have been wonderful to develop the
ABI in the open for nanoMIPS but unfortunately needs-must and we had to do
it in private. I hope our decisions stand the test of time and any guidance
you can give to sure up the definition is most appreciated.

> There seems to be a lot that is incomplete or inconsistent in this
> document (or inconsistent between it and other nanoMIPS documents).
>
> To start with, do you have floating point in the architecture and ABI or
> not?  This ABI says it's purely a soft-float ABI.  But the p32 Porting
> Guide says there are 32 floating-point registers, of which 8 are
> argument registers.  Then in the ISA manual, I see no mention of
> floating point beyond avoiding it between LL and SC if it might trap.

As it stands there is no floating point in the architecture, that will come
in time. We have considered a lot of the floating-point aspects and as you
point out we do have some lingering references to the design. We will go
through and eliminate those.
 
> Then your argument passing ABI says structs are treated as a sequence of
> 32-bit chunks, either all in registers or all on the stack.  But then
> you give an example marking a struct as passed by reference, when the
> earlier description of argument passing made no mention of that.  I also
> see nothing about whether later arguments could go in registers after a
> struct was forced to the stack because it wouldn't all fit there.  I
> also see nothing about how non-struct/union arguments larger than 64
> bits (e.g.
> _Complex double) are passed.  What's the argument promotion for an _Bool
> argument (i.e. as a byte it has to be 0 or 1, but are the high 24 bits
> defined as 0 when passed?)?  What about _Complex float when there's only
> room for one 32-bit value in a register - is it all on the stack, or
> split between registers and stack? (it's not 64-bit aligned in memory,
> so I'd expect it not to need 64-bit alignment when passed as an argument
> - the 32-bit powerpc ABI *does* 64-bit align it in register arguments,
> but that's an artifact of documenting accidental existing practice, not
> something you want when designing a new ABI).
> 
> Then you list [signed] long twice in the table of types, as both 32-bit
> and 64-bit, presumably the latter needs to be long long.  long double is
> described as quad precision, but listed as 64-bit, which contradict each
> other (and it's not C99 only).
> 
> I see you're using GCC 6 at present, but when using GCC 7 or later
> you'll have _FloatN and _FloatNx types (TS 18661-3) as well, so it would
> be a good idea to document the ABIs for those.

Thanks for all these points. I will bring all this up with the team and
come back with clarifications. There is certainly more work to do in
refining this section.
 
> Does the p32 ABI use PLTs (like most non-MIPS architectures) or not?

As it stands we have not defined any PLTs but may consider introducing
them for code that is not link time relaxable. The justification for this
is that we are targeting a relaxable PIC model by default in a
(potentially) dynamically linked environment. At link time we can eliminate
all the indirect GOT calls back to direct BALC/BC for locally bound symbols.

We therefore get the same benefit in the end of using direct calls for
local symbols, as well as not having to introduce the indirection that a
PLT involves. This same approach means we have no need for COPY relocs in
this default setup.

There are some further link time optimisations to be implemented but most
of the key logic is already in place.

Thanks,
Matthew