> Richard Earnshaw wrote:
> 
> > 
> > I would put the chances of it not being as batting around zero.
> 
> So you mean it is 99% fixed....

It means that a better argument than has been presented so far (basically, 
bad programs might not work) to justify the loss of benefit to those 
people who need enums to use the minimal space (if they don't then they 
will be forced to not use enums).

> > 
> > > to specify variable-length enumeration types, where enums have
> > > the same size as the smallest integer type that will contain all their
> > > enumarators.
> 
> Does this allow enums outside [-2^31..2^31) ?
No, you can have unsigned enums as well, giving you [0..2^32).  The 
selection rules determine the underlying type.

I'm not sure if anyone has considered longer enums than that (long long).

> I don't think there are many enums visible in 'traditional' structures.
> IMHO they aren't strongly typed enough to be useful.

Indeed, I very much doubt that such a selection of packed enums is going 
to lead to regular bumping of shared lib numbers as has been claimed.

> > >  * Enums will tend to be types that are slow to load and store  on ARMv3,
> > >    which is our default compiler target.
> > 
> > Most enums that I've seen are in the range 0-255; very few will need more
> > than this.
> 
> But doesn't the 'load signed byte' not appear until v4?
Correct.

>  So even loads
> near the start of structures will require 2 shifts to sign extend (or 1
> to place at the top of the register).

Which is one reason why the enum container for an enum set in the range 
0..127 should be unsigned.

Incidentally, the compiler is quite good these days at elminating 
unnecessary sign extensions.  For example, for equality comparisons it can 
eliminate the sign extension entirely, while for inequality comparisons 
with a constant it can normally eliminate the second shift.

> 
> Maybe there should be an option for the system build to use a later set?

You are always free to build a library with compiler options such as 
-mcpu=strongarm, though of course such a library would then only run on 
armv4 or later.

> Any maths (ok any comparisons after maths) require that the value be
> truncated correctly.  This all generates code bloat.

This doesn't follow.  Most maths on an enum would require that it be 
promoted to an int first.  As soon as this has been done, you don't really 
have an enum anymore.

> The other problem (does it affect arm?) whether the top bits of
> registers user to pass and return arguments / results to / from
> functions are guaranteed to be correctly sign extended.

The APCS promotion rules say that enums will be correctly promoted before 
being passed as arguments in registers.

> Having any integers that are not the true 'natural' size for the
> architecture (32bits for almost everything except ILP64 alpha) costs
> code.

Provide some concrete evidence...

> Does gcc support 'enum' bit fields?

Yes, but that isn't relevant.  They aren't permitted by c89.

> What is the ratinal behind picking varialbe sized enums?  After all most
> choices these days are made on efficiency, not size basis.

Maybe in the desktop arena, but in many other arenas that isn't true.  The 
ARM ABI is, by necessity, a compromise between the needs of the different 
market spaces it addresses.

>  (Isn't the
> change to structure alignments - all 32 bit? instead of 'as required by
> largest member' - one that gains a slight efficiency saving at the cost
> of a small amount of space?)

I think you've got this backwards.

> On a related subject, do we use 16bit or 32bit wide characters?
We have wide characters in NetBSD, but I don't know what size they are off 
hand.

R.