sh4 abi doc

sh4 abi doc

[Elena Zannoni]

Is there such a doc publically available?
I cannot spot one easily on the www.hitachisemiconductor.com website.

thanks
Elena

RE: sh4 abi doc

[Clarke, Stephen]

> From: Elena Zannoni [mailto:ezannoni@redhat.com] 
> Sent: Thursday, September 26, 2002 8:20 AM
> 
> Is there such a doc publically available?
> I cannot spot one easily on the www.hitachisemiconductor.com website.

Hi,

SuperH are in the process of preparing an SH-4 ABI
document.  It's not quite ready for public release -
it's in the final editing stage internally.  When it is
released, SuperH will make it available for download
from the SuperH software website:
http://www.superh-software.com
and will announce it on the mailing lists.

Regards,
Steve.

RE: sh4 abi doc

[Elena Zannoni]

Clarke, Stephen writes:
 > > From: Elena Zannoni [mailto:ezannoni@redhat.com] 
 > > Sent: Thursday, September 26, 2002 8:20 AM
 > > 
 > > Is there such a doc publically available?
 > > I cannot spot one easily on the www.hitachisemiconductor.com website.
 > 
 > Hi,
 > 
 > SuperH are in the process of preparing an SH-4 ABI
 > document.  It's not quite ready for public release -
 > it's in the final editing stage internally.  When it is
 > released, SuperH will make it available for download
 > from the SuperH software website:
 > http://www.superh-software.com
 > and will announce it on the mailing lists.
 > 

thanks!
in the meantime, do you know what is the official rule for returning
results on the stack, instead of in the return register?
Seems that gdb and gcc are disagreeing on this.
Gdb expects structs to be returned on the stack if their size is > 1.

thanks
Elena


 > Regards,
 > Steve.

RE: sh4 abi doc

[Clarke, Stephen]

> From: Elena Zannoni [mailto:ezannoni@redhat.com] 
> Sent: Thursday, September 26, 2002 9:51 AM

> in the meantime, do you know what is the official rule for returning
> results on the stack, instead of in the return register?
> Seems that gdb and gcc are disagreeing on this.
> Gdb expects structs to be returned on the stack if their size is > 1.

Here's what we have:

"Aggregate types not bigger than 8 bytes that have the same size and
alignment as one of the integer scalar types are returned in the same
registers as the integer type they match.

"For example, a 2-byte aligned structure with size 2 bytes has the
same size and alignment as a short int, and will be returned in R0.
A 4-byte aligned structure with size 8 bytes has the same size and
alignment as a long long int, and will be returned in R0 and R1.

"When an aggregate type is returned in R0 and R1, R0 contains the first
four bytes of the aggregate, and R1 contains the remainder. If the size
of the aggregate type is not a multiple of 4 bytes, the aggregate is
tail-padded up to a multiple of 4 bytes. The value of the padding is
undefined.

"All other aggregate types are returned by address. The caller function
passes the address of an area large enough to hold the aggregate value
in R2. The called function stores the result in this location."

I hope that makes sense, it was difficult to describe both clearly and
accurately!  

Actually, the SH-4 ABI documentation that Red Hat supplies with
the gnupro tools says the same thing in fewer words, but (IMO)
not as clearly.

Steve.

Re: sh4 abi doc

[Andrew Cagney]

> "When an aggregate type is returned in R0 and R1, R0 contains the first
> four bytes of the aggregate, and R1 contains the remainder. If the size
> of the aggregate type is not a multiple of 4 bytes, the aggregate is
> tail-padded up to a multiple of 4 bytes. The value of the padding is
> undefined.

Suggest clarifying this.  In particular how tail ``tail-padding'' 
interacts with LE and BE.  I think I know what this means (having seen 
the MIPS) but (having seen the MIPS) I also know how badly it can be 
botched :-(

enjoy,
Andrew

RE: sh4 abi doc

[Elena Zannoni]

Clarke, Stephen writes:
 > 
 > 
 > > From: Elena Zannoni [mailto:ezannoni@redhat.com] 
 > > Sent: Thursday, September 26, 2002 9:51 AM
 > 
 > > in the meantime, do you know what is the official rule for returning
 > > results on the stack, instead of in the return register?
 > > Seems that gdb and gcc are disagreeing on this.
 > > Gdb expects structs to be returned on the stack if their size is > 1.
 > 
 > Here's what we have:
 > 
 > "Aggregate types not bigger than 8 bytes that have the same size and
 > alignment as one of the integer scalar types are returned in the same
 > registers as the integer type they match.
 > 
 > "For example, a 2-byte aligned structure with size 2 bytes has the
 > same size and alignment as a short int, and will be returned in R0.
 > A 4-byte aligned structure with size 8 bytes has the same size and
 > alignment as a long long int, and will be returned in R0 and R1.
 > 
 > "When an aggregate type is returned in R0 and R1, R0 contains the first
 > four bytes of the aggregate, and R1 contains the remainder. If the size
 > of the aggregate type is not a multiple of 4 bytes, the aggregate is
 > tail-padded up to a multiple of 4 bytes. The value of the padding is
 > undefined.
 > 
 > "All other aggregate types are returned by address. The caller function
 > passes the address of an area large enough to hold the aggregate value
 > in R2. The called function stores the result in this location."
 > 

Ah, so gdb is wrong. The cutoff is 8 bytes.

 > I hope that makes sense, it was difficult to describe both clearly and
 > accurately!  
 > 

yes. except for BE/LE differences. But you clarified that already.

 > Actually, the SH-4 ABI documentation that Red Hat supplies with
 > the gnupro tools says the same thing in fewer words, but (IMO)
 > not as clearly.
 > 

Doh, I should have thought about that. 

Elena


 > Steve.

RE: sh4 abi doc

[Clarke, Stephen]

> From: Andrew Cagney [mailto:ac131313@redhat.com] 
> Sent: Thursday, September 26, 2002 10:19 AM
> To: Clarke, Stephen
> Cc: Elena Zannoni; gdb@sources.redhat.com
> Subject: Re: sh4 abi doc
> 
> 
> > "When an aggregate type is returned in R0 and R1, R0 
> contains the first
> > four bytes of the aggregate, and R1 contains the remainder. 
> If the size
> > of the aggregate type is not a multiple of 4 bytes, the aggregate is
> > tail-padded up to a multiple of 4 bytes. The value of the padding is
> > undefined.
> 
> Suggest clarifying this.  In particular how tail ``tail-padding'' 
> interacts with LE and BE.  I think I know what this means 
> (having seen 
> the MIPS) but (having seen the MIPS) I also know how badly it can be 
> botched :-(

Yes ...  when describing how parameters are passed, we have:

"When the size of an aggregate parameter is not a multiple of
4 bytes, it is tail padded up to a multiple of 4 bytes. The value
of this padding is undefined. For little-endian targets the
padding will appear at the most significant end of the last element,
for big-endian targets the padding appears at the least significant
end of the last element."

(Here an 'element' is a 4-byte chunk of the aggregate).

But the position of the padding is not described for return
values.  The intention is that return values are padded in
the same way as parameters, but you're right: it should be
stated explicitly.

Thanks,
Steve.

RE: sh4 abi doc

[Clarke, Stephen]

> From: Elena Zannoni [mailto:ezannoni@redhat.com] 
> Sent: Thursday, September 26, 2002 10:43 AM
> 
> The cutoff is 8 bytes.

Yes: anything bigger than 8 bytes is definitely
returned in memory.

But the cutoff is not "clean", because structs smaller
than this could also be returned in memory, if they
don't pass the "same size and alignment as an integer
type" rule.

For example, in

  struct s { char c[3]; } wibble;
  struct s foo(void) {  return wibble; }

the return value from foo() will be in memory, not
in R0, because there is no 3-byte integer type.

Sorry if that was obvious already, I just wanted to
be sure.

Steve.

RE: sh4 abi doc

[Elena Zannoni]

Clarke, Stephen writes:
 > > From: Elena Zannoni [mailto:ezannoni@redhat.com] 
 > > Sent: Thursday, September 26, 2002 10:43 AM
 > > 
 > > The cutoff is 8 bytes.
 > 
 > Yes: anything bigger than 8 bytes is definitely
 > returned in memory.
 > 
 > But the cutoff is not "clean", because structs smaller
 > than this could also be returned in memory, if they
 > don't pass the "same size and alignment as an integer
 > type" rule.
 > 
 > For example, in
 > 
 >   struct s { char c[3]; } wibble;
 >   struct s foo(void) {  return wibble; }
 > 
 > the return value from foo() will be in memory, not
 > in R0, because there is no 3-byte integer type.
 > 
 > Sorry if that was obvious already, I just wanted to
 > be sure.
 > 
 > Steve.


Very helpful. I hadn't noticed this variant, indeed.

Thanks
Elena

Re: sh4 abi doc

[Andrew Cagney]

> Clarke, Stephen writes:
>  > > From: Elena Zannoni [mailto:ezannoni@redhat.com] 
>  > > Sent: Thursday, September 26, 2002 10:43 AM
>  > > 
>  > > The cutoff is 8 bytes.
>  > 
>  > Yes: anything bigger than 8 bytes is definitely
>  > returned in memory.
>  > 
>  > But the cutoff is not "clean", because structs smaller
>  > than this could also be returned in memory, if they
>  > don't pass the "same size and alignment as an integer
>  > type" rule.
>  > 
>  > For example, in
>  > 
>  >   struct s { char c[3]; } wibble;
>  >   struct s foo(void) {  return wibble; }
>  > 
>  > the return value from foo() will be in memory, not
>  > in R0, because there is no 3-byte integer type.
>  > 
>  > Sorry if that was obvious already, I just wanted to
>  > be sure.
>  > 
>  > Steve.
> 
> 
> Very helpful. I hadn't noticed this variant, indeed.

Ah, the ``gcc struct return'' rule.  Perhaphs we need a generic function 
that specifies this.

enjoy,
Andrew