Re: Problem involved porting LCC to a 8 bit microcontroller

"Michael Tiomkin" <tmk@netvision.net.il>
8 Sep 2006 00:27:34 -0400

          From comp.compilers

Related articles
Problem involved porting LCC to a 8 bit microcontroller amker.cheng@gmail.com (2006-09-06)
Re: Problem involved porting LCC to a 8 bit microcontroller englere_geo@yahoo.com (Eric) (2006-09-08)
Re: Problem involved porting LCC to a 8 bit microcontroller tmk@netvision.net.il (Michael Tiomkin) (2006-09-08)
Re: Problem involved porting LCC to a 8 bit microcontroller toby@telegraphics.com.au (toby) (2006-09-08)
Re: Problem involved porting LCC to a 8 bit microcontroller gah@ugcs.caltech.edu (glen herrmannsfeldt) (2006-09-08)
Re: Problem involved porting LCC to a 8 bit microcontroller raffaele.salmaso@gmail.com (Raffaele Salmaso) (2006-09-08)
| List of all articles for this month |

From: "Michael Tiomkin" <tmk@netvision.net.il>
Newsgroups: comp.compilers
Date: 8 Sep 2006 00:27:34 -0400
Organization: http://groups.google.com
References: 06-09-007
Keywords: code, lcc

amker.cheng@gmail.com wrote:
> 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
macros.


    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.


    Michael


Post a followup to this message

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