is this too crazy compiler behavior??

[asmboy]

Been using ver 4.085 very happily - mostly with 18F parts - since 4.085 was released.

Just moved a simple timer0 , polled handler - to count down 10msec increments - that works like a charm on many 18f parts like 18f4620 4520 2423 452 etc etc etc - with timer0 in 8 bit mode -

Today I tried to use the same code on an 18f887 - but found that
--woundtix - on the f887 caused a near instant exit!
the routine exited instantly in under 1 sec when told to use a 10 sec delay.

I traced my problem to decrementing a declared
unsigned int16 woundtix - where - in each case using 8 mhz int clock- no PLL or fuse funnies etc . and polled from main() -


Check out this LST extract - where I was forced to switch to using
the second method of decrementing to keep the code working properly
on the 16F part .. bizarre - or is it me ??

[FvM]

[asmboy]

all i know is that the FIRST version - using --woundtix;
does NOT "count right" - based on a stopwatch test -
and ONLY when compiled for a 16f887 !!!

same code - same everything - works perfectly on an 18F4620 --

i was only porting the code from the 18f to reduce the cost of production on a fully tested and working prodcut.


anyway - the second one DOES perform properly -- on both PICS-

it was only after a lot of head scratching that i resorted to:
var=var-1; syntax - and was puzzled as heck as to what was going on.

i only posted because i was shocked to find very basic code that was "broken" like that.

[PCM programmer]

I didn't find a problem.

First I made the program below in MPLAB. I put breakpoints on the line
that sets woundtix to 0xFFFF and on the while(1) line at the end. I enabled
the MPLAB stopwatch function. I ran the program until it stopped at the
first breakpoint in MPLAB simulator and then I zeroed the Stopwatch.
Then I ran it to the last breakpoint. I got a stopwatch duration of
170.4924 ms for the loop code:

[FvM]

My point is, I don't see a problem with the code shown in your post.
if(woundtix) --woundtix compiles to identical assembly level code in recent CCS C versions. Nevertheless,
to make the problem understandable, please post a complete compilable example that allows to reproduce it.
There may be something that doesn't reveal in the shown example.

[asmboy]

found it after more head scratching

there are various #includes - involved here

i was fooling myself with a fixed #bit T0IF definition that was correct for 18F family - located earlier in the program - but no so hot for 18F cuz it reads as an address beyond 16F reg space - as a '1' no matter how often i tried to clear it .....so T0IF was ALWAYS set etc etc etc

when i changed what i thought was the faulty math - i had also at the same time - switched to the include file i had used with a much older 16F project -- that happened to use the correct register bit address for T0IF -

it was ending early because T0IF would not stay clear - no ta math bug ;-))

i am happy to report that both means of decrementing do work after all.

mea culpa

[andrewg]