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

[Robert Suchanek <Robert dot Suchanek at mips dot com>]

Hi,



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

> > docs/MIPS_nanoMIPS_ABI_supplement_01_02_DN00179.pdf

>

> 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 Matthew already mentioned - there is no floating point at this time

but it was being considered with bits not removed in the docs.



>

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



This will be clarified in the documentation.  An argument can occupy up

to two register widths and anything larger would be passed by reference.

A reference 'consumes' one argument register.



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



They could go in registers as larger objects are passed by reference

until we run out of argument registers.



>  I also see

> nothing about how non-struct/union arguments larger than 64 bits (e.g.

> _Complex double) are passed.



This needs clarification.  An argument can be up to 64-bits (for 32-bit ABI),

otherwise it cannot be allocated an argument register, and hence, passed

by reference. In general, there are a handful of cases when

an argument is passed by reference:



- it's a variable sized type

- it's larger than 2 register widths

- it's a vector type



>  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?)?



We treat it as an unsigned char so essentially we would zero-extend it.

This is what should happen and it does seem reasonable.



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



It would be passed on the stack.  It is not because we enforce 64-bit

alignment that this gets passed on the stack but rather that we do not

permit splitting between registers and stack (i.e. no partial args in

GCC internals terms).



>

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



It appears to be copy and paste error. Will be fixed.



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



Good point and this will need documenting.  Thanks for pointing this out.



Regards,

Robert