PBP and PBPL

[Darrel Taylor]

argument out of range (34218 not between 0 and 32767)

That means your program is larger than the 32k bytes (16k words) available on the 4550.
<br>

[keymuu]

That means your program is larger than the 32k bytes available on the 4550.
<br>

Could that mean anything else?

When compiling with PBP (not PBPL) it is 28632 bytes and of course there can not be any longs yet involved when still struggling to get it compile with PBPL. Or, would PBPL build bigger code than PBP when not using VAR LONGs ?

[Darrel Taylor]

In PBPL, ALL system variables are LONGs. ALL intermediate math is done as LONGs. Even multiplying 2 bytes can use LONGs.

Longs take more code than words.
So a PBPL program will ALWAYS be larger than a PBPW program.
<br>

[keymuu]

In PBPL, ALL system variables are LONGs. ALL intermediate math is done as LONGs. Even multiplying 2 bytes can use LONGs.

Longs take more code than words.
So a PBPL program will ALWAYS be larger than a PBPW program.
<br>

Thank you Darrel, thank you indeed You are real PIC wizard

So, I will see in future if it is worth to go back to PBP from PBPL...
The code compiled before with PBP=28632 bytes, then I moved away from the code that math that needs more precision and compiled it then with PBP=26026. This indicates that my 16 math eats 2606 bytes that later can be replaced with 32bit math and surely not taking so many lines (and bytes), I removed 280 lines. Now compiled with PBPL=28274, it will be interesting to see how close to limit (32k) the final compilation will be.

Thanks again, and thank you all others also, Dave, Alain, Charles ...

[keymuu]

In PBPL, ALL system variables are LONGs. ALL intermediate math is done as LONGs. Even multiplying 2 bytes can use LONGs.

Longs take more code than words.
So a PBPL program will ALWAYS be larger than a PBPW program.
<br>

Hopefully this is the last question on this subject:

When using PBPL you are not allowed in any part of your formula to have any intermediate results over 32bits! Is this a correct claim or not?

The question arise from the following formula:
R = ( (H^2) + ((L/2)^2) ) / H and for example
where
L = 315,103 -> 315103 (=LONG)
H = 37,234 -> 37234 (=WORD)

That should give R=703,9 (=WORD)

But instead of that you run to a strange error. When I remove that formula from the program it compiles correctly altogether to 28640 bytes. When I change the formula just to (L/2)*(L/2) gives also a similar error
Error[126].... (32770 not between 0 and 32767) indicating that the (L/2)*(L/2) would take 4130 byte (=32770-28640)
If I use the original formula (R=...) then the exceeding number groves from 32770 to 32886 an increase of 116 byte.

What is going on? Is it really true that you can not calculate in the middle of your formula any bigger value than 2 147 483 647!
(L/2)*(L/2) gives 2 482 247 515 and that is just little over but it is over and one could suspect that to be the reason to this.

How to overcome such a situation? Please let me know

[mackrackit]

Try dividing "L" by 10 at the first to knock it down a bit.
Then after all of the other calculations multiply the 10 back in.
As long as the final result is smaller than a LONG it should work.

It might keep everything down to word size too.

[keymuu]

Try dividing "L" by 10 at the first to knock it down a bit.
Then after all of the other calculations multiply the 10 back in.
As long as the final result is smaller than a LONG it should work.

It might keep everything down to word size too.

Thanks Dave!

Nice try... however it doesn't work, you need all the bits to get the result R correct. Easy to test this with Excel

Actually (L/2)^2 could be calculated earlier in the PC and programmed as a constant to PIC. Then it would reduce the formula
to
R=(H*H + Lsqr2)/H
and
in this case the constant Lsqr2 = 24 822 475 152 and this is too big also for the LONG variable but now used only as a input to the formula. We could also see the formula like this:
R= (H*H)/H + Lsqr2/H = H + Lsqr2/H, this would reduce all calculation to just one little bit tricky (too many bits) part

=> Lsqr2/H

How could this be compiled easily? 35 bits with 16 bits, is it easily done or does it demand some special technique?

If you know, please advice ...

[keymuu]

Try dividing "L" by 10 at the first to knock it down a bit.
Then after all of the other calculations multiply the 10 back in.
As long as the final result is smaller than a LONG it should work.

It might keep everything down to word size too.

Dave! After all there might be some idea ...

Let's say L=350123 and H=37234

And as you remember Lsqr2/H = L*L/2*2/H
that also could be written
L/4 * L/H

Then L/4=87530,75 ................. L/4 still over 16bits
L/H=9,403314175 ........
But if we divide L with 8 we get L/8=43765,375
and if we take the integer part 43765 (within 16bits!) and the decimal part 0,375. Let us call the integer part Lint and the decimal part Ldec, and we could first calculate Ldec= 8*0,375 = 3
Now we would have everything small enough... After the calculation we need to divide the result with 1000 and after that use only one decimal.

We are seeking for (L/2)*(L/2)/H/1000 ........if we write the formula

((8*Lint)+Ldec) * ((8*Lint)+Ldec)/ 4 / H / 1000 we will get the same result but

PBP does not compile it correctly and you get 0 as the result. If you remove the /1000 you still get 0. If you do not divide by H you get 1022, if you try ((8*Lint)+Ldec)/1000 you get 22. ?????????? it should give 350 !

You can see what I'm trying to do... How should one split things to go right in such a situation?
Could you please help me with this "small" problem

[mackrackit]

Looks like you are on the right track.

I think the problem now might be to many (()).. The compiler is confused.

((8*Lint)+Ldec) * ((8*Lint)+Ldec)/ 4 / H / 1000

L8 = 8 * Lint
LT = L8 + Ldec
R = LT * LT /4 / H / 1000

Maybe???