Re: More dev86 changes (0.16.5)

[mjn3@codepoet.org (Manuel Novoa III)]

Robert,

On Fri, Jul 26, 2002 at 08:55:39AM +0100, Robert de Bath wrote:
> On Thu, 25 Jul 2002, Manuel Novoa III wrote:
> 
> > > One other thing I would like to see, which is an optimising measure more
> > > than anything: When bcc lays out the variables at any level, if it sorts
> > > them in descending order of size before laying them out, it will really
> > > minimise the number of padding bytes needed to ensure correct alignment.
> > > It is for this reason that when I am writing C code, I always list all
> > > of the variables in descending size order,
> >
> > Same here.  ;-)
> 
> This gains you nothing unless you are in the habit of using single byte

On occassion.  I know that on i386 I've seen gcc produce smaller code
when I declared some small counters or boolean values as char rather
than int.

> char values even then there's gotya ...
> 
> In 32bit mode int and long are the same size.
> In 16bit mode everything is aligned on 2 bytes boundries (including the stack).
> 
> In fact if you put them in _decending_ order of size you may actually
> be hurting the code because the BP register points at the top (highest
> memory address) of the current stack frame so the variables defined
> first have the smallest offsets and can probably be accessed using
> smaller (and possibly faster) instructions, however, this only applies
> if the offset exceeds 128 bytes.

Also relevant in structure defs if you're going to ref the structure via
a pointer.  Putting the most commonly referenced field first lets it be
referenced without an additional offset.  I think I saved about 100-200
bytes in the uClibc stdio code by doing that with the FILE struct.  Of
course, then you also may need to adjust the layout to avoid holes.

On the topic of bcc feature additions, things I've thought about are:
1) long long support since it is in C99 and (selfishly) since it would
   allow me to avoid rewriting a couple of uClibc functions.
2) wide char support, which of course, that brings up the question of
   whether or not wide chars be 16 bits (to save space) or 32 bits
   (for better compatibility) in 16 bit mode.

Also, I suppose we all wish for a better optimizer.  I'd love to not
have to resort to the "register char *" as loop counter hack anymore.

Manuel