|Problem involved porting LCC to a 8 bit microcontroller email@example.com (2006-09-06)|
|Re: Problem involved porting LCC to a 8 bit microcontroller firstname.lastname@example.org (Eric) (2006-09-08)|
|Re: Problem involved porting LCC to a 8 bit microcontroller email@example.com (Michael Tiomkin) (2006-09-08)|
|Re: Problem involved porting LCC to a 8 bit microcontroller firstname.lastname@example.org (toby) (2006-09-08)|
|Re: Problem involved porting LCC to a 8 bit microcontroller email@example.com (glen herrmannsfeldt) (2006-09-08)|
|Re: Problem involved porting LCC to a 8 bit microcontroller firstname.lastname@example.org (Raffaele Salmaso) (2006-09-08)|
|From:||"Michael Tiomkin" <email@example.com>|
|Date:||8 Sep 2006 00:27:34 -0400|
> Just a student project !Porting porting LCC to a 8 bit microcontroller
> with which char is 8 bit and int is 16bit.
> But I found in LCC character and short-integer actual arguments are
> always promoted to the coresponding type even in the presence of a
> prototype!(And does there any place in it did similar thing?)
> So I have to use 2 8bit regsters for a char type argument!This is
> unbearable here!
The compiler is allowed to do promotions of the arguments.
If you change the calling conventions, check first if your processor
needs int to be aligned on an even address. In this case you'll have
sometimes to insert padding for the arguments placed on the stack, and
ensure that the frame is always properly aligned (padding at the end).
Alternatively, if you don't need padding, you should change the vararg
The reason for this behaviour of lcc and many other compilers for
RISC processors is that the size of int is usually equal to the size
of the registers, and promotion to int makes faster function calls.
Unfortunately, this is not the case for your processor.
> I want to change the front end, but not sure. All I have to do is
> change codes for function declarations and definitions in decl.c?
> Further more , in arithmetric computing "char c1,c2; c1 = c1 + c2;"
> does lcc promote char into int? I doubt of it because there isn't an
> dag operator for ADDI1!
Your problem is C language, and not lcc. Find any book about
standard (ISO/ANSI) C and look at the rules of promotion. Your c1 and
c2 will be promoted to int, then the sum of the values will be
computed, and after that the result will be truncated to char. In your
case it's not a big problem, because all the computations of the
higher 8 bits will be dead code and the optimizer will remove them in
one of the phases of compilation.
Return to the
Search the comp.compilers archives again.