Richard Earnshaw wrote:
> This would change if we moved to padding structures up to a word; and i=
t=20
> is what we were originally intending to do when moving to ELF. But that=
=20
> would make use less compatible with ARM's toolkit (and it also makes=20
> porting some applications a pain in the butt, since most other machines=
 --=20
> particularly x86 --  don't do this).

Is there some information somewhere available how structures should be pa=
dded
and aligned on ARM processors? I just know the behaviour of the Norcroft =
C
compiler under RiscOS. There structures were always 32-Bit aligned, and i=
nside
a structure 32 Bit quantities were always 32-Bit aligned. I do not rememb=
er
what was with 16 Bit quantities, but I guess they were 16-Bit aligned
as Acorn suggested to use:

LDR reg,[adr] this uses the fact that the content of [adr] is rotated in =
a way
              so that the LSB of reg contains that byte that is located a=
t [adr]
MOV reg,reg,lsl#16
MOV reg,reg,lsr#16 for unsigned / MOV reg,reg,asr#16 for signed

for loading shorts.

Well, I am just interested in the speed of the code. You have seen the ba=
d
impact of unaligned and unpadded structures on the speed!=20

I would prefer structures only allowed to be 32-Bit aligned. I would like
the structures to be padded, so that 32-Bit quantities are 32-Bit aligned=
, and
16-Bit quantities are 16-Bit aligned. It seems that Linux' GCC is doing t=
his
by default (and even if it is told not to do so...) How can I explain thi=
s to
NetBSD's GCC, that I want this behaviour?

What does ARM's toolkit do? One should think that they prefer their code =
to be
fast, and for the major range of applications were ARM processors are use=
d this
is the most important fact, compatibility to x86 structures is not import=
ant.
So they should do it the same way?

Peter
--=20
Email: teich-p@rcs.urz.tu-dresden.de   WWW: rcswww.urz.tu-dresden.de/~tei=
ch-p