public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
* Ping : H8/300  ABI Document
@ 2004-03-30 13:10 Anil Paranjape
  2004-04-01 20:58 ` Jim Wilson
  0 siblings, 1 reply; 4+ messages in thread
From: Anil Paranjape @ 2004-03-30 13:10 UTC (permalink / raw)
  To: Kazu Hirata; +Cc: gcc

Hi,

Please review change suggested in H8 ABI document from following link,
http://gcc.gnu.org/ml/gcc/2004-03/msg01325.html

Regards,
Anil Paranjpe

-----Original Message-----
From: Anil Paranjape 
Sent: Tuesday, March 23, 2004 3:24 PM
To: 'Kazu Hirata'; gnuh8@gnuh8.org.uk
Cc: 'gcc@gcc.gnu.org'
Subject: RE: ABI Document


Hi,

Please find following sentence from  http://gcc.gnu.org/projects/h8300-abi.html,

Structure Alignment
Unless __attribute__ ((packed)) is attached to the declaration of a struct, each structure member is aligned 
to a multiple of 2 bytes on H8/300 and of 4 bytes on H8/300H and H8S.

I think this is slightly misleading statement. 
Consider following testcase,

struct test {
  unsigned short a;         /* Address 0,1 */
  unsigned short b;         /* Address 2,3 */
};
  struct test t;
int  main (void)
{
  t.b = 1;
  return 0;
}

Compiler options passed are 
-ms -ms2600 -fverbose-asm -S

Generated assembly for above testcase is following,
        .file   "test.c"
        .h8300s
        .section .text
        .align 1
        .global _main
_main:
        mov.l   er6,@-er7       ;#,
        mov.l   er7,er6 ;#,
        mov.w   #1,r2   ;#, tmp17
        mov.w   r2,@_t+2        ;# tmp17, t.b
        sub.w   r2,r2   ;# <result>
        mov.w   r2,r0   ;# <result>, <result>
        mov.l   @er7+,er6       ;#,
        rts
        .size   _main, .-_main
        .comm   _t,4,2
        .end
        .ident  "GCC: (GNU) 3.4.0 20040303 (prerelease)"

Analysis:

Assuming above mentioned structure alignment is true then instruction "mov.w   r2,@_t+2" used for accessing t.b in generated assembly should be wrong. The instruction should be "mov.w   r2,@_t+4".
According to structure alignment every structure member is aligned to 4 bytes . So padding mentioned in following structure definition should be correct,
struct test {
  unsigned short a;         /* Address 0,1 (2,3 padding) */
  unsigned short b;         /* Address 4,5 (6,7 padding) */
};

But actually it is not the case. By default structure is aligned to 4 byte boundary. 
So instruction for accessing t.b in generated assembly is correct.
The default alignment of structure is 4 bytes unless __attribute__ ((packed)) is used.

I suggest to change the text of structure alignment in ABI document like following,

Structure Alignment
Unless __attribute__ ((packed)) is attached to the declaration of a struct or union, each structure or union is aligned 
to a multiple of 2 bytes on H8/300 and of 4 bytes on H8/300H and H8S. The compiler inserts padding to maintain the alignment of its members. The sizeof a structure is always multiple of its alignment and this may require tail padding. 


Regards,
Anil Paranjpe

-----Original Message-----
From: Kazu Hirata [mailto:kazu@cs.umass.edu]
Sent: Monday, January 19, 2004 11:22 AM
To: gnuh8@gnuh8.org.uk
Subject: ABI Document


Hi,

I just added a document describing H8 ABI for GCC.

http://gcc.gnu.org/projects/h8300-abi.html

I'll try to make it complete over time.  Suggestions, questions, etc,
are all welcome.

Maybe interrupt function handling needs to be described.

Kazu Hirata

-- 
GNUH8 Mailing List | If you encounter difficulties using this service
                   | email: listmaster@gnuh8.org.uk
                   | http://www.gnuh8.org.uk/

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Ping : H8/300  ABI Document
  2004-03-30 13:10 Ping : H8/300 ABI Document Anil Paranjape
@ 2004-04-01 20:58 ` Jim Wilson
  0 siblings, 0 replies; 4+ messages in thread
From: Jim Wilson @ 2004-04-01 20:58 UTC (permalink / raw)
  To: Anil Paranjape; +Cc: gcc

Anil Paranjape wrote:
> Structure Alignment
> Unless __attribute__ ((packed)) is attached to the declaration of a struct, each structure member is aligned 
> to a multiple of 2 bytes on H8/300 and of 4 bytes on H8/300H and H8S.

This is a maximum.  Fields get natural alignment (alignment same as 
size) up to this maximum.  So shorts are always 2 byte aligned, but 
4-byte ints get 2-byte alignment on H8/300 and 4-byte alignment on H8S.

Structure alignment is the max of the alignment of all fields.

Your suggested wording is not correct.  The structure in your example 
still has only 2-byte alignment even whwn compiled for H8S.
         .comm   _t,4,2
gives it a 4-byte size and 2-byte alignment.  This is because shorts 
always have 2-byte alignment.
-- 
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com

^ permalink raw reply	[flat|nested] 4+ messages in thread

* RE: Ping : H8/300  ABI Document
  2004-04-02  8:44 Anil Paranjape
@ 2004-04-05 23:57 ` Jim Wilson
  0 siblings, 0 replies; 4+ messages in thread
From: Jim Wilson @ 2004-04-05 23:57 UTC (permalink / raw)
  To: Anil Paranjape; +Cc: gcc

On Fri, 2004-04-02 at 00:43, Anil Paranjape wrote:
> I am suggesting to change the description of "structure alignment" to proper one. 

Your suggested wording is wrong.  I think the current wording is better
than your replacement, because your replacement says nothing about
alignment of fields.  I think the current one can be improved by
changing "a multiple of" to "at most"
-- 
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com

^ permalink raw reply	[flat|nested] 4+ messages in thread

* RE: Ping : H8/300  ABI Document
@ 2004-04-02  8:44 Anil Paranjape
  2004-04-05 23:57 ` Jim Wilson
  0 siblings, 1 reply; 4+ messages in thread
From: Anil Paranjape @ 2004-04-02  8:44 UTC (permalink / raw)
  To: Jim Wilson; +Cc: gcc

Hi Jim,

>This is a maximum.  Fields get natural alignment (alignment same as 
>size) up to this maximum.  So shorts are always 2 byte aligned, but 
>4-byte ints get 2-byte alignment on H8/300 and 4-byte alignment on H8S.

>Structure alignment is the max of the alignment of all fields.

I agree to this. 

In my example, there were two short variables as members of structure. 
Each will be treated as separate member. 

> Structure Alignment
> Unless __attribute__ ((packed)) is attached to the declaration of a struct, each structure member is aligned 
> to a multiple of 2 bytes on H8/300 and of 4 bytes on H8/300H and H8S.
Hence as per above statement,
Each short variable(each structure member) should be aligned to multiple of 4 bytes on H8S.

This is not the case. Because as you have rightly said "shorts always have 2-byte alignment".
So size of structure is 4 bytes and alignment is 2 bytes. 

I am suggesting to change the description of "structure alignment" to proper one. 

Thanks and Regards,
Anil


-----Original Message-----
From: Jim Wilson [mailto:wilson@specifixinc.com]
Sent: Friday, April 02, 2004 2:29 AM
To: Anil Paranjape
Cc: gcc@gcc.gnu.org
Subject: Re: Ping : H8/300 ABI Document


Anil Paranjape wrote:
> Structure Alignment
> Unless __attribute__ ((packed)) is attached to the declaration of a struct, each structure member is aligned 
> to a multiple of 2 bytes on H8/300 and of 4 bytes on H8/300H and H8S.

This is a maximum.  Fields get natural alignment (alignment same as 
size) up to this maximum.  So shorts are always 2 byte aligned, but 
4-byte ints get 2-byte alignment on H8/300 and 4-byte alignment on H8S.

Structure alignment is the max of the alignment of all fields.

Your suggested wording is not correct.  The structure in your example 
still has only 2-byte alignment even whwn compiled for H8S.
         .comm   _t,4,2
gives it a 4-byte size and 2-byte alignment.  This is because shorts 
always have 2-byte alignment.
-- 
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2004-04-05 23:57 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-03-30 13:10 Ping : H8/300 ABI Document Anil Paranjape
2004-04-01 20:58 ` Jim Wilson
2004-04-02  8:44 Anil Paranjape
2004-04-05 23:57 ` Jim Wilson

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).