Re: Small values in large registers (char,short,...) (Jacob Navia)
7 Dec 1997 22:08:19 -0500

          From comp.compilers

Related articles
Small values in large registers (char,short,...) (Jakob Engblom) (1997-12-02)
Re: Small values in large registers (char,short,...) (Henry Spencer) (1997-12-05)
Re: Small values in large registers (char,short,...) (1997-12-07)
| List of all articles for this month |

From: (Jacob Navia)
Newsgroups: comp.compilers
Date: 7 Dec 1997 22:08:19 -0500
Organization: Compilers Central
References: 97-12-010
Keywords: code, architecture

Hi jakob!

I have written an lcc centered compiler system for windows 95/NT. You
can see the source code and get the system (for free) at When I put a char/short value in a
register I will expand or ignore the high end bit depending on the
unsigned/signed attribute of the data. This is easy in x86
architectures since there is an expanding instruction in the

movsx _char%,eax

will expand the high bit of the character into all unused bits of the
32 bit register eax. Similarly:

movzx _char,%eax

will ignore the high bit and put zeroes in the bits 8-31. In other
architectures you *have* to synthethize those expansions. If not you
will always encounter the problems you mention. To do that it would be
easy to initialize the destination register to -1 in the case of
signed chars or zero the register in the case of unsigned, THEN put
the data in the register. Any other solution will make for a buggy
compiler.You can always try to catch some errors, but you are sure to
miss something sometimes. Besides, the complexity of the compiler will
increase by a factor that is not justified by the very small gains of
performance that you can expect. At today's clock speed, initializing
a register to a costant is an extremely fast operation. If you are
concerned about code size, remember that for initializing a register
to zero an

xor reg,reg

will zero it. If you want to initialize to minus one, you could do:

xor reg,reg
dec reg

In the case you have the decrement operation as is the case in the
x86. I think the sparc processors use the 'small constant' operation,
so a substraction of one could be done without storing a 32 bit

The alternative, i.e. keeping track of when a register was loaded with
some small costant/data and some bits in the register contain garbage
is enormous in development/debugging time. It is just not worth the

Yours sincerely
Jacob Navia Logiciels/Informatique
41 rue Maurice Ravel Tel (1)
93430 Villetaneuse Fax (1)

Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.