PBPL 2.50b (possible) For/Next ?BUG? or just the way it is...

While working/testing/failing those souped up divide routines, I came across something.
Don't know if it's a bug, or just plain unavoidable...

Code:

---

mn = -2147483600 'almost max'd out at 31 bits
mx = 2147483600 'almost max'd out at 31 bits
st = 1234567 'step size can vary quite a bit
x var long

For x = mn to mx step st
    lcdout $fe , 1 , HEX4 x.word1 , ":" , HEX4 x.word0
Next x

---

The loop never stops! Ever!
It seems that when the step size is larger than the difference between 2^31 -1 and mx, x will roll over from a positive number to a negative number (high bit set) and the loop will keep running. Conversely, if using a negative step size, x will roll over from a negative number to a positive number and the loop will keep running as before.
Looks to me like it's an unavoidable situation...
Any thoughts?

If the "step" is to big no matter what size of variable, (byte,word) wouldn't the same thing happen, a roll over?

Quote:

---

Originally Posted by mackrackit

If the "step" is to big no matter what size of variable, (byte,word) wouldn't the same thing happen, a roll over?

---

I would think so. But it seems that with PBPL that internally everything is dealt with as though it were a LONG (case in point, those division routines I've been monkeying with). I'm fairly sure the rest of the math is dealt with in the same fashion. Therefore, a byte or word, might not act the same way. Not sure. It's just something I noticed yesterday.

It will be the weekend before I get back to the bench. I am going to play with it.

I was playing with a taylor series awhile back and gave up, thought it was me and my bad coding... probably was :o but maybe it is something with PBPL?

Quote:

---

Originally Posted by mackrackit

I was playing with a taylor series awhile back and gave up, thought it was me and my bad coding... probably was :o but maybe it is something with PBPL?

---

Not a Darrell Taylor series I hope!!! :D

Quote:

---

Originally Posted by skimask

Not a Darrell Taylor series I hope!!! :D

---

Nope. But might be some relation.

This Taylor
http://en.wikipedia.org/wiki/Brook_Taylor
any resemblance?

Been playing with this and it is strange.
Used your vars in this code.

Code:

---

'18F6680
    Asm
    ERRORLEVEL -205
    Endasm
    DEFINE OSC 20

    @ __CONFIG    _CONFIG1H, _OSC_HS_1H
    @__CONFIG    _CONFIG2H, _WDT_ON_2H & _WDTPS_128_2H
    @__CONFIG    _CONFIG4L, _LVP_OFF_4L
   
    SOUT    VAR PORTF.4
    X      VAR LONG
    MN      VAR LONG
    MX      VAR LONG
    ST      VAR LONG
   
    mn = -2147483600 'almost max'd out at 31 bits
    mx = 2147483600 'almost max'd out at 31 bits
    st = 1234567 'step size can vary quite a bit
   
    START:
    SEROUT2 SOUT,16468,["START",13,10]
    GOSUB SKI_COUNT
    SEROUT2 SOUT,16468,["STOP",13,10]
    END
   
    SKI_COUNT:
  '  For x = mn to MX step 10000'NEVER STOPS
  '  For x = mn to MX step 100000 'NEVER STOPS
    FOR X = -2000000000 TO 2000000000 STEP 2146483647 'STOPS,BUT STRANGE
    SEROUT2 SOUT,16468,[SDEC X,13,10]
    Next x
    RETURN

---

The output when it does not stop(roll over)

Code:

---

2147446400
2147456400
2147466400
2147476400
-2147480896
-2147470896
-2147460896
-2147450896

---

And the STRANGE output when it does stop.

Code:

---

START
-2000000000
146483647
-2002000002
144483645
-2004000004
142483643
-2006000006
140483641
-2008000008
138483639
-2010000010
136483637
-2012000012
134483635
-2014000014
132483633
-2016000016
130483631
-2018000018
128483629
-2020000020
126483627
-2022000022
124483625
-2024000024
122483623
-2026000026
120483621
-2028000028
118483619
-2030000030
116483617
-2032000032
114483615
-2034000034
112483613
-2036000036
110483611
-2038000038
108483609
-2040000040
106483607
-2042000042
104483605
-2044000044
102483603
-2046000046
100483601
-2048000048
98483599
-2050000050
96483597
-2052000052
94483595
-2054000054
92483593
-2056000056
90483591
-2058000058
88483589
-2060000060
86483587
-2062000062
84483585
-2064000064
82483583
-2066000066
80483581
-2068000068
78483579
-2070000070
76483577
-2072000072
74483575
-2074000074
72483573
-2076000076
70483571
-2078000078
68483569
-2080000080
66483567
-2082000082
64483565
-2084000084
62483563
-2086000086
60483561
-2088000088
58483559
-2090000090
56483557
-2092000092
54483555
-2094000094
52483553
-2096000096
50483551
-2098000098
48483549
-2100000100
46483547
-21
02000102
44483545
-2104000104
42483543
-2106000106
40483541
-2108000108
38483539
-2110000110
36483537
-2112000112
34483535
-2114000114
32483533
-2116000116
30483531
-2118000118
28483529
-2120000120
26483527
-2122000122
24483525
-2124000124
22483523
-2126000126
20483521
-2128000128
18483519
-2130000130
16483517
-2132000132
14483515
-2134000134
12483513
-2136000136
10483511
-2138000138
8483509
-2140000140
6483507
-2142000142
4483505
-2144000144
2483503
-2146000146
483501
STOP

---

Quote:

---

Originally Posted by mackrackit

Been playing with this and it is strange.

---

Those are the results I was talking about.
Strange....Yes....Unexpected....Not really, especially when dealing with integers, whole numbers, binary conversions, etc.etc.etc.
I can't think of any really efficient way to check for those kinds of bounding conditions without getting crazy with the code.
Like I said, it's just one of those things. Doesn't happen too often, and hopefully the person it happens to can understand why it happens and how to avoid it.

Quote:

---

Doesn't happen too often, and hopefully the person it happens to can understand why it happens and how to avoid it.

---

Well... I kind of understand why it rolls over.

But the results when it does work has me baffled.
+-+-+-+-
Why?

Quote:

---

Originally Posted by mackrackit

Well... I kind of understand why it rolls over.

But the results when it does work has me baffled.
+-+-+-+-
Why?

---

It's overflowing WAYYY too far, flipping the sign bit, making the For/Next loop think it's still within the boundaries so it keeps adding in the next step value.
Eventually, it doesn't overflow far enough to either flip the sign bit or when it does overflow, it overflows just enough that the difference between the current count and the max (or min) and the step value goes out of the boundaries of the For/Next loop...

Doesn't make a lot of sense, does it?......

Quote:

---

Doesn't make a lot of sense, does it?......

---

I wonder if the folks at MELabs knows about this?

Quote:

---

Originally Posted by mackrackit

I wonder if the folks at MELabs knows about this?

---

Probably do, but it seems to me like this particular scenario would be such an uncommon thing that a guy could either deal with it, or MeLabs could BLOAT PicBasicPro with internal checking code...ya know...like Windows. PBP seems to me like it's fairly well streamlined...I don't want/need garbage thrown in there...
I'll fire off a note to them and see what happens...actually, I'll just direct their attention to this thread....probably a lot easier. :)

PLEASE DO NOT MAKE PBP LIKE WINDOWS!!!

Are you sure you want to run that code?

CLICK HERE.

If you really want to run the code enter your user name and password here.

To verify it is you, enter your 83 digit PIN here.

SORRY... that number is not correct.

Would you like to send an error report?

Ok...That's it...You forced me into...
On that project of mine where I made the videos of the OBD2 reader...
I'm going to make a BSOD and add that into the program and the videos! :D