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