[IRCServices Coding] GCC3

[Kelmar K. Firesun]

----- Original Message -----
From: "Andrew Church" <achurch at achurch.org>
To: <ircservices-coding at ircservices.za.net>
Sent: Monday, February 25, 2002 7:39 AM
Subject: RE: [IRCServices Coding] GCC3


> >>      The major problem I have with GCC 3.0 is that it reorders
structures
> >> (or at least did at one point), which would break convert-db, and in
> >> general is a Bad Idea (among other things it prevents you from laying
> >> structures on top of data in memory).  Does anyone know if this has
been
> >> fixed or if there's a way around it?
> >
> >Are you sure it reordered them? It might just have changed the padding
> >between members, which compilers have been known to do in the past.
> >Anyhow, I haven't tried convert-db yet but I will when I get the chance
>
>      To be perfectly honest, that's based on hearsay--I haven't confirmed
> it one way or the other.  But I do recall quite a lot of discussion on
that
> point, so I'd like to have confirmation that it does work before
> "officially" endorsing it.
>

I could certanly see it padding the data structures.
This would be to optimize memory access by keeping things
aligned with the CPU's WORD size.  64bits in the case of
most Intel Pentiums if I recall correctly.

For example, if you have a structure like so:

struct foo
{
    int_16 bar;
    int_8 baz;
};

The compiler would append or prepend (depending on compiler)
on an extra 40bits of data to align it in memory on each
allocation.

If this is the case there SHOULD be a command line option
to tell the compiler to disable this optimization.  In other
cases, you can disable this on a structure by structure basis
using a "packed" (or something similar) keyword.

Note, that this optimization could also apply to an array.

This is a very common optimization for speed in many compilers.
I'm actually very surprised that GCC would just now be
implementing it.

Kelmar K. Firesun (IRL: Bryce Simonds)
Acting Admin: dream.esper.net