romcc ramblings...

[Eric W. Biederman]

Romcc is coming along quite nicely.  I keep fixing a corner
case here and there but it quite usable and getting more so.

One area where it falls short is in it's handling of lots of small
variables.  The classic question is:  If I declare my small variables
to be chars will romcc be able to store them in both AL and AH?

And unfortunately the answer is no.  Using the AH, BH, CH, and DH
at least when I tried it did not work well.  Treating all of the
registers the same seems to work much better.

A similar question is can romcc pack 2 byte values in a random
register?  The answer again is no.  But for a different reason
extracting and reinserting the values requires an extra register,
so it is not a transformation I want to perform automatically.

With that being said I do think it is worth having romcc support
keeping multiple values in a register.  Otherwise I will wind
up writing a bunch of macros like:

#define LATENCY(MIN) (((MIN) >> 8) & 0xff)
#define SET_LATENCY(MIN, LATENCY) ((MIN) = (((MIN) & ~(0xff << 8)) | (((LATENCY) & 0xFF) << 8)))
#define CYCLE_TIME(MIN) ((MIN) & 0xff)
#define SET_CYCLE_TIME(MIN, CYCLE_TIME) ((MIN) = (((MIN) & ~0xff) | ((CYCLE_TIME) & 0xFF)))


Which look ugly are a bit of a pain to write.  I looked an C actually
has a mechanism to do this already.  bit fields in structures.  For
doing I/O to the outside world they are not portable.  So their use
is discouraged.

For internal values that are just going to be used internally by
a program, say packing multiple values in a single register they are 
portable and a decent way to describe what is going on.

So to keep 2 byte values in I register I could do:
struct {
        unsigned latency:8;
        unsigned cycle_time:8;
} min;

I have not implemented this but I plan to.  For both programmer control and 
ease of use it looks like a win.


Eric