Implicit cast

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Implicit cast

2,191 Views
wolfy
Contributor I
I am using ANSI-C/cC++ Compiler for HC12 V-5.0.28 Build 5073
and I am looking for a compiler option to solve the following problem:
----code----
unsigned long lResult; // 32bit
unsinged int iFac1 = 0x1000, iFac2 = 0x1000; // 16bit

lResult = iFac1 * iFac2;
^^-------------
So, lResult should hold the 32bit result of the multiplication. Actually its only an 16bit value, which I fully agree with, but I need to know whether its possible to assign the correct 32bit result to lResult without casting.
Typecasting one of the Factors it not an option for me, due to some difficult reasons!

Is there a way that the compiler can recognize the 32bit type of lResult and apply this knowlege to the computation of the R-value before assignment?

thx,
wolfy
Labels (1)
Tags (1)
0 Kudos
5 Replies

679 Views
CompilerGuru
NXP Employee
NXP Employee
The ANSI-C standard states that this computation has to be done with int arithmetic, so no, there is no option to explicitly disable this part of the ANSI C specification.
Realistically, you will have to perform some sort of cast, either by an explicit cast to one of the arguments or by an implicit cast by assigning iFac1 or iFac2 to a long first and then performing the computation with this new local variable.
unsigned long lResult; // 32bit
unsigned int iFac1 = 0x1000, iFac2 = 0x1000; // 16bit
void fun(void) {
  lResult = iFac1 * (unsigned long)iFac2;
}

void fun2(void) {
  unsigned long local= iFac2;
  lResult = iFac1 * l;
}

Both of these operations result in a simple EMUL for the multiplication, so it generates less code than without the cast.
0 Kudos

679 Views
Lundin
Senior Contributor IV
Actually, this is a common problem with code written by PC-programmers, tested on a PC and then ported to a 16-bit environment. The PC programmer might be unaware of the so called "integer promotions" in ANSI C, since every operation like the one in the example will be using 32-bit integers. It would have worked fine on a PC for that reason.

Further, the programmer is the one responsible for estimating whether a certain variable will overflow, not the compiler.
0 Kudos

679 Views
wolfy
Contributor I
Thanks for helping me so fast.

Your posts also reflect my opinion, that the code has to be corrected.
(It's not my code, I just got it to make it run on a HCS12X )

According to the author it already has been tested on other 16bit-Processors
and worked fine. Do you, from your experience, think that's possible?
Or didn't he test it "long" enough :smileywink:
0 Kudos

679 Views
Lundin
Senior Contributor IV
It depends on the nature of the values. If (iFac1 * iFac2) is less than 65535 for most of the time, it would be hard to detect. It also depends on how critical the value is. Because it will be truncated to a value less than 65536 if you get overflow.

There is also a chance that the compiler used to write the code on isn't ANSI C compatible. There are plenty of crappy compilers for embedded systems out there.
0 Kudos

679 Views
pittbull
Contributor III
Hi,
Try this:

unsigned long lResult; // 32bit
unsinged int iFac1 = 0x1000, iFac2 = 0x1000; // 16bit

lResult = iFac1;
lResult *= iFac2;

:smileywink:
0 Kudos