PBP and PBPL

[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???

[keymuu]

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

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

Maybe???

Thanks Dave!

I did not mention in the previous mail that I don't trust in PBPL, as it seems to me that it can not correctly show how much space your code will take when you are as close to the limit as 3k or so.

So, your idea is excellent, no doubt When dealing with the reliably basic 16bits one should be able to shop the thing even smaller.... or perhaps, if one could fool PBP somehow and use DIV32 where the result is 32 bit. The manual 4.17.8 DIV32 (page 37) says:
"PBP and PBPW's multiply (*) function operates as 16-bit x 16-bit multiply yielding a 32 bit internal result. ....
....
In many cases it is desirable to be able to divide the entire 32-bit result of the multiply by a 16-bit number for ...
...
..... DIV32 relies that a multiply was just performed and that the internal compiler variables still contain the 32-bit result of the multiply...."
Those internal are referred as R0 and R2, right? R0=High and R2=Low, correct?

Then multiplication (manual 4.17.1) there are two operators '*/' and '**'
"The '*/' operator discards the least significant byte of the result (byte0) and returns the 4 higher bytes to the result variable...
... The '**' operator is similar, but ignores two bytes instead of one.... This gives a result that is shifted 16 places to the right..."
Are here any known internal variables (like R0,R2) involved?

Could one possible use the above, using R0,R2 and so, to achieve to do what I'm trying to do?

Please, if you know could you shear you knowledge of how to use internal variables for DIV32, how about those for multiplication?

I did a small check and it seems to me that PBP is using R0-R8 for something.
I kind of know that R0 and R2 is for DIV32, however never utilized them yet.
I suppose that those others are also some intermediate variables. If you know would you please be so kind and tell where they are used and if you want to you could also perhaps give some examples of the use..

[mackrackit]

I am afraid I do not understand now. I was thinking the only reason to chop the number up (factor it) was because at one point the value was larger than 32 bits, then once that was dealt with 16 bit had it covered.

Is the math working correctly now for your formula?

What am I missing here.

As far as the code size goes with PBPL, every value is a LONG, even 1. So that is where the extra code space comes from.

I did not mention in the previous mail that I don't trust in PBPL, as it seems to me that it can not correctly show how much space your code will take when you are as close to the limit as 3k or so.

The code space used as far as I know is calculated correctly in PBP or PBPL. What is making you think other wise?