avr-libc-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [avr-libc-dev] [bugs #11396] Large number jumps to hyperspace


From: Paul Schlie
Subject: Re: [avr-libc-dev] [bugs #11396] Large number jumps to hyperspace
Date: Mon, 27 Dec 2004 03:05:36 -0500
User-agent: Microsoft-Entourage/11.1.0.040913

(Sorry, apparently I can't count zeros; as 16,000,000 is obviously about
24-bits, and should be divide fine; but unfortunately still larger than
a 16-bit int, but would have expect a warning if the value was truncated,
and resulted prior to use),


> From: Paul Schlie <address@hidden>
>> It's a total pain trying to find tool bugs by looking at the
>> asm output in a simulator. I've been looking at:
>> 
>> #include<inttypes.h>
>> 
>> int
>> main(void)
>> {
>>      uint16_t baud=9600;
>>      uint16_t reg=16000000/(16*baud) - 1;
>>      return 0;
>> }
>> 
>> using gcc flags to put out rtl code (it'll take me a while
>> to understand it).
> 
> If it's of any help, the code as written shouldn't actually do anything,
> as it will be optimized away. If you want to force an expression to be
> evaluated as written although it's assigned value may not be used, designate
> all interesting variables as volatile for testing purposes.  Also as a heads
> up, if baud has a known value, reg's will also be statically computed (i.e.
> at compile time), so don't expect to see anything other than it's
> pre-computed value being assigned.  Lastly, which is likely your problem, if
> baud is not known statically, reg will computed dynamically (assuming it's
> value is used), but 16000000 is a ~34 bit number, resulting in a 64-bit (DI
> mode) division if designated as a long long computation, but it's not clear
> to me that 64-bit arithmetic has ever properly worked for the avr target; or
> you should have seen a warning that value was too large an int literal,
> where the value would have been truncated to a 16-bit int value = 0x2400 =
> 9216, which divided by (16*baud), would result in 0 - 1, resulting in -1,
> which may have affected a conditional expression or hw timer somewhere else
> in your code or system, or something like that.
> 
> 
> 
> 
> _______________________________________________
> AVR-libc-dev mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/avr-libc-dev






reply via email to

[Prev in Thread] Current Thread [Next in Thread]