sergio masci wrote:

>>   int aa=500, bb=1000, cc=700; // only example values, not const
>>   int result;
>>   
>>   // 1- the easy way, not good:
>>   result = (aa * bb) / cc; 
>> 
>>   // 2- better (works):
>>   result = ((long)aa * bb) / cc; 

>   byte aa=10, bb=100, cc=120; // only example values, not const
>   byte result;
> 
>   // 2- better (works):
>   result = ((int)aa * bb) / cc; 

> So yes XCSB will treat your (1) as your (2) without the need for coercion.

So if I understand you correctly, XCSB will evaluate this result always by
using a (8 * 8 -> 16) multiplication and a (16 / 8 -> 8) division. 

If this is correct, there is a slight disadvantage in the cases where I can
guarantee that (aa * bb) never will be more than 127 (or the 32767 if we're
talking about int and long). 


> It is good that you do this but it would be much better if you did not 
> need to. C is a truely wonderful language for generateing obscure code 

Just out of curiosity: what language did you use to program XCSB?

> void *ptr;

I'm not sure what's more dangerous: void pointers or type casts :)  I very
rarely use them. You showed why...


>>   // 3- for longer calculations that involve multiple scaled 
>>   // values my preference, often tracking the possible ranges 
>>   // of input/output for some code lines in line comments:
>>   long temp = aa;
>>   temp *= bb;
>>   temp /= cc;
>>   ASSERT( (INT_MIN<=temp) && (temp<=INT_MAX) );
>>   result = (int)temp;

>> This is actually where we get back to James's original post. This manual
>> tracking of ranges in comments as I sometimes do in such situations could
>> somehow be formalized and at least be checked by the compiler, throwing
>> warnings for calculations that may lead to data loss.

Have you thought about adding range handling to your compiler? I'm not sure
it makes sense, as some sources seem to claim that in all but the most
trivial cases, the automatically calculated boundaries grow so quickly that
they become all but useless, and because boundaries and ranges are not
everything (think for example about loss of resolution due to wrong
sequence of multiplication and division), but with an additional feature
that would allow the definition of not only the variable start ranges, but
also intermediate ranges?

If that could be made working, that would be a truly unique feature that
AFAIK no other embedded compiler has.

Gerhard

-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist