Complete.Org: Mailing Lists: Archives: freeciv-dev: March 2002:
[Freeciv-Dev] Re: [Patch] Bool cleanup of options.c

[Freeciv-Dev] Re: [Patch] Bool cleanup of options.c

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: Tony Stuckey <stuckey@xxxxxxxxxxxxxxxxx>
Cc: "Ross W. Wetmore" <rwetmore@xxxxxxxxxxxx>, freeciv development list <freeciv-dev@xxxxxxxxxxx>
Subject: [Freeciv-Dev] Re: [Patch] Bool cleanup of options.c
From: Raimar Falke <hawk@xxxxxxxxxxxxxxxxxxxxxxx>
Date: Mon, 18 Mar 2002 18:31:43 +0100
Reply-to: rf13@xxxxxxxxxxxxxxxxxxxxxx

On Mon, Mar 18, 2002 at 10:59:31AM -0600, Tony Stuckey wrote:
> On Mon, Mar 18, 2002 at 08:48:53AM +0100, Raimar Falke wrote:
> > On Sun, Mar 17, 2002 at 10:13:54PM -0500, Ross W. Wetmore wrote:
> > > Is it even noticeable, or do the extra code instructions to handle
> > > bytes swamp the data memory savings for anything but a bool[]?
> > 
> > What extra code instructions?
>       These will certainly be present on Alpha architectures.  While I
> don't know anything about ARM and some other chips, I don't think that
> x86, M68K, or Sparc will have any issues at all.  (Other that Raimar's
> noted occasional sign-extend at function return for ABI reasons)

I haven't found any extra instructions on Alpha. But it hard since gcc
assign registers differently and causes so a lot of noise.

> > > Also, memory access is actually optimized for word or word multiples. If
> > > random bytes cause other accesses to cross these boundaries, you lose in
> > > a big way.
> > 
> > Quite possible.
>       GCC should pad out to reasonable alignments, other compilers might
> or might not.

AFAIK this depends more on the ABI than on the compiler. Althought the
compiler can add extra padding.


 email: rf13@xxxxxxxxxxxxxxxxx
 "On the eigth day, God started debugging"

[Prev in Thread] Current Thread [Next in Thread]