[ECOS] Yet another ARM alignment question

[ECOS] Yet another ARM alignment question

[Wilson Kwan]

I've read through the eCos list regarding ARM alignment problems and am
wondering if anyone out there can lend a few suggestions. I am faced with a
general porting problem of some legacy Intel code. Of course all the
structures were packed on byte boundaries and with some having structures
within structures.

My question is has anyone solved the word and dword alignment problems on
ARM? Is is any combination of gcc compiler options that will overcome this
limitation albeit at a performance cost. What about an alignment trap
handler? Anyone have any sample code on how to write one of these or a
pointer to some good documentation?

Thanks again in advance,

Wilson

Re: [ECOS] Yet another ARM alignment question

[elf]

IIRC, the compilers are supposed to align correctly for the given
architecture.  In fact, if you want to pack against it's better
judgement, you need to use the __ALIGNMENT__ (__ALIGN__?) directive.

On Tue, Apr 24, 2001 at 11:51:49PM -0400, Wilson Kwan wrote:
> I've read through the eCos list regarding ARM alignment problems and am
> wondering if anyone out there can lend a few suggestions. I am faced with a
> general porting problem of some legacy Intel code. Of course all the
> structures were packed on byte boundaries and with some having structures
> within structures.
> 
> My question is has anyone solved the word and dword alignment problems on
> ARM? Is is any combination of gcc compiler options that will overcome this
> limitation albeit at a performance cost. What about an alignment trap
> handler? Anyone have any sample code on how to write one of these or a
> pointer to some good documentation?
> 
> Thanks again in advance,
> 
> Wilson

Re: [ECOS] Yet another ARM alignment question

[Lewin A.R.W. Edwards]

Hello Wilson,

>My question is has anyone solved the word and dword alignment problems on
>ARM? Is is any combination of gcc compiler options that will overcome this
>limitation albeit at a performance cost. What about an alignment trap

If you specify -fpack-struct on the gcc command line, gcc will not align 
data items in structures and will generate multiple ldrh/ldrb/strh/strb 
instructions to access the misaligned data items in those structures; is 
that what you're asking? The performance cost of doing this globally is 
_high_ and it's best avoided!

Is this a theoretical question or do you have an actual problem? (Can you 
post a little sample code along with a description of the symptom?) I can't 
see where it would be an issue except in certain structures (e.g. my 
problem I had a while back generating structs to reflect various FAT 
structures). gcc will normally handle pointer arithmetic and dereferencing 
for you without difficulty.

The more efficient way to solve the latter problem is to specify just those 
structures as packed, which is what I'm doing, e.g. :

// Master Boot Record
typedef struct {
         unsigned char fill[0x1be];      // boot code
         PARTENTRY partitions[4];        // partition table
         unsigned char sig_55;           // 55h boot signature
         unsigned char sig_aa;           // AAh boot signature
} __attribute__((packed)) MBR, *PMBR;


=== Lewin A.R.W. Edwards (Embedded Engineer)
Work: http://www.digi-frame.com/
Personal: http://www.zws.com/ and http://www.larwe.com/

"... a man who is endowed with real qualities of leadership will be tempted 
to refrain from taking part in political life; because [...] the situation 
does not call for a man who has a capacity for constructive statesmanship 
but rather for a man who is capable of bargaining for the favour of the 
majority. Thus the situation will appeal to small minds and will attract 
them accordingly."

Re: [ECOS] Yet another ARM alignment question

[Wilson Kwan]

Hi Lewin,

> Hello Wilson,
>
> >My question is has anyone solved the word and dword alignment problems on
> >ARM? Is is any combination of gcc compiler options that will overcome
this
> >limitation albeit at a performance cost. What about an alignment trap
>
> If you specify -fpack-struct on the gcc command line, gcc will not align
> data items in structures and will generate multiple ldrh/ldrb/strh/strb
> instructions to access the misaligned data items in those structures; is
> that what you're asking? The performance cost of doing this globally is
> _high_ and it's best avoided!

I tried -fpack-struct to no effect. I believe that it may be a broken
option. I can get code to run properly if I use __attribute__ ((packed)). My
problem is that we have so much legacy code that it is not feasible to go
through all of it and add this attribute at this time. I'm running
arm-elf-gcc version 2.95.2 on Win NT 2000. I'm willing to take the
performance hit for now and will fix the general problem when I have more
time.

>
> Is this a theoretical question or do you have an actual problem? (Can you
> post a little sample code along with a description of the symptom?) I
can't
> see where it would be an issue except in certain structures (e.g. my
> problem I had a while back generating structs to reflect various FAT
> structures). gcc will normally handle pointer arithmetic and dereferencing
> for you without difficulty.

I've attached a test piece of code that exhibits the problem. I'm sure many
have encountered this before. The makefile uses the -fpack-struct option but
doesn't seem to fix the problem. Defining PACKED and recompiling does. Do
you know if there was a patch for gcc to fix this on Win NT?

Thanks again Lewin. As always you're a great help.

Wilson

Re: [ECOS] Yet another ARM alignment question

[Lewin A.R.W. Edwards]

Hi Wilson!

> > If you specify -fpack-struct on the gcc command line, gcc will not align
> > data items in structures and will generate multiple ldrh/ldrb/strh/strb
>
>I tried -fpack-struct to no effect. I believe that it may be a broken
>option. I can get code to run properly if I use __attribute__ ((packed)). My

It works for me with gcc 2.95.2 (under cygwin/win2000). The code size is 
increased substantially, and the speed is affected very noticeably though 
(around 15% slowdown in my MPEG-1 software decoder, for instance).

>problem is that we have so much legacy code that it is not feasible to go
>through all of it and add this attribute at this time. I'm running

I know that problem. That is one of the reasons I started with 
-fpack-struct (also I was having trouble getting the attribute directive to 
work properly). When I delved deeper, I found that very few of my 
structures actually needed to be packed (only a few that mirror structures 
supplied by external hardware), so I got rid of -fpack-struct.

>I've attached a test piece of code that exhibits the problem. I'm sure many
>have encountered this before. The makefile uses the -fpack-struct option but
>doesn't seem to fix the problem. Defining PACKED and recompiling does. Do
>you know if there was a patch for gcc to fix this on Win NT?

The 2.95.2 I'm running was installed exactly per Red Hat's instructions on 
sources.redhat.com. No special patches.

I'll take a look at your code this afternoon (I'm about to go into a 
MEETING.. argh!), but note well! you should delete your build tree and 
recompile eCos itself from scratch with -fpack-struct if you intend to 
compile your application with that flag. Although it will partly work if 
you don't, Bad Things will happen if you give any eCos API a pointer inside 
one of your unaligned structures, since the eCos code will assume that 
everything is aligned.

Note that I have only tested -fpack-struct with eCos 1.3.1, though I don't 
see an obvious reason why it should break current sources unless there are 
assembly language routines in the OS that dereference pointers generated by 
C code.

=== Lewin A.R.W. Edwards (Embedded Engineer)
Work: http://www.digi-frame.com/
Personal: http://www.zws.com/ and http://www.larwe.com/

"... a man who is endowed with real qualities of leadership will be tempted 
to refrain from taking part in political life; because [...] the situation 
does not call for a man who has a capacity for constructive statesmanship 
but rather for a man who is capable of bargaining for the favour of the 
majority. Thus the situation will appeal to small minds and will attract 
them accordingly."

Re: [ECOS] Yet another ARM alignment question

[Wilson Kwan]

[-- Attachment #1: Type: text/plain, Size: 1903 bytes --]

Sorry, forgot to attach the code snippets.


> Hi Lewin,
>
> > Hello Wilson,
> >
> > >My question is has anyone solved the word and dword alignment problems
on
> > >ARM? Is is any combination of gcc compiler options that will overcome
> this
> > >limitation albeit at a performance cost. What about an alignment trap
> >
> > If you specify -fpack-struct on the gcc command line, gcc will not align
> > data items in structures and will generate multiple ldrh/ldrb/strh/strb
> > instructions to access the misaligned data items in those structures; is
> > that what you're asking? The performance cost of doing this globally is
> > _high_ and it's best avoided!
>
> I tried -fpack-struct to no effect. I believe that it may be a broken
> option. I can get code to run properly if I use __attribute__ ((packed)).
My
> problem is that we have so much legacy code that it is not feasible to go
> through all of it and add this attribute at this time. I'm running
> arm-elf-gcc version 2.95.2 on Win NT 2000. I'm willing to take the
> performance hit for now and will fix the general problem when I have more
> time.
>
> >
> > Is this a theoretical question or do you have an actual problem? (Can
you
> > post a little sample code along with a description of the symptom?) I
> can't
> > see where it would be an issue except in certain structures (e.g. my
> > problem I had a while back generating structs to reflect various FAT
> > structures). gcc will normally handle pointer arithmetic and
dereferencing
> > for you without difficulty.
>
> I've attached a test piece of code that exhibits the problem. I'm sure
many
> have encountered this before. The makefile uses the -fpack-struct option
but
> doesn't seem to fix the problem. Defining PACKED and recompiling does. Do
> you know if there was a patch for gcc to fix this on Win NT?
>
> Thanks again Lewin. As always you're a great help.
>
> Wilson
>
>

[-- Attachment #2: Makefile --]
[-- Type: text/x-makefile, Size: 849 bytes --]

PKG_INSTALL_DIR = //d/purple/ecos/targets/7211_install
XCC = arm-elf-gcc -mcpu=arm7tdmi -D__EDB7211

ifeq ($(XCC),sh-elf-gcc)
CFLAGS	      = -ggdb
else
CFLAGS	      = -g
endif

CXXFLAGS      = $(CFLAGS)

# -mstructure-size-boundary=8

EXTRACFLAGS   = -Wall -I$(PKG_INSTALL_DIR)/include -ffunction-sections -fdata-sections \
		-fpack-struct

LDFLAGS       = -nostartfiles -L$(PKG_INSTALL_DIR)/lib -Wl,--gc-sections
LIBS	      = -Ttarget.ld -nostdlib

LD	      = $(XCC)
XCXX	      = $(XCC)

###### RULES

.PHONY: all clean CCCHECK

all: test3.exe

clean:
	-rm -f *.o
	-rm -f *.exe
	-rm -f *.srec
	-rm -f *.ld

CCCHECK:
ifeq ($(XCC),)
	@echo You must set XCC to the name of your cross-compiler
	@false
endif

%.o: %.c
	$(XCC) -c -o $*.o $(CFLAGS) $(EXTRACFLAGS) $<

test3.o: test3.c

test3.exe: CCCHECK test3.o
	$(LD) $(LDFLAGS) -o $@ test3.o $(LIBS)


[-- Attachment #3: test3.c --]
[-- Type: text/x-c, Size: 2125 bytes --]

#include <cyg/kernel/kapi.h>
#include <cyg/infra/diag.h>
#include <stdio.h>
#include <stdlib.h>

#ifdef  PACKED

#define PACK    __attribute__ ((packed))

#else

#define PACK

#endif

typedef struct tagRectType {
        unsigned short left;
        unsigned short top;
        unsigned short right;
        unsigned short bottom;
        } PACK RectType;

typedef struct tagWinType {
        char                   reserved;
        RectType               cBounds;
        void *                 data1;
        long                   ldata;
        struct tagWinType *    next;
        } PACK WinType;


int main (
   int   argc,
   char *argv[])
   {
   char       buffer [64];
   WinType   *wwwPtr;
   int        count;

   for (count = 0; count < 64; count++)
      {
      *(buffer + count) = (char) (count % 16);
      } // end for

   diag_printf ("Memory contents\n");
   diag_printf ("===================================================\n");
   for (count = 0; count < 64; count++)
      {
      unsigned char   byte;

      byte = *(buffer + count);

      diag_printf ("%02x ", byte);

      if ( (count + 1) % 16 == 0)
         {
         diag_printf ("\n");
         } // endif
      } // end for

   diag_printf ("\n\nSizeof WinType = %d\n\n", sizeof (WinType));

   count = 0;

   count ++;
   for (count = 0; count < 5; count++)
      {
      wwwPtr = (WinType *) &buffer [count];
      diag_printf ("WinType.reserved        = %02x\n" , wwwPtr->reserved       );
      diag_printf ("WinType.cBounds.left    = %04x\n" , wwwPtr->cBounds.left   );
      diag_printf ("WinType.cBounds.top     = %04x\n" , wwwPtr->cBounds.top    );
      diag_printf ("WinType.cBounds.right   = %04x\n" , wwwPtr->cBounds.right  );
      diag_printf ("WinType.cBounds.bottom  = %04x\n" , wwwPtr->cBounds.bottom );
      diag_printf ("WinType.data1           = %08lx\n", wwwPtr->data1          );
      diag_printf ("WinType.ldata           = %08lx\n", wwwPtr->ldata          );
      diag_printf ("WinType.next            = %08lx\n", wwwPtr->next           );
      diag_printf ("\n");
      } // end for

   return 0;
   } // main