PBP and PBPL

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

[keymuu]

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.


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

Ok, I was ambiguous ... sorry

Please, take a look at #26, there I try to explain why PBPL can't be trusted.

However, the main point shortly:
As the code is now compiled without errors or warnings with PBP it is 26406 bytes + bootloader=1k.

If I compile it, the same code, with PBPL it is 28682 bytes (???), however with a bunch of warnings and one
"Error[126] \PBP\PBPPI18.LIB 690 : argument out of range (32940 not between 0 and 32767)"
and I learned earlier it indicates that the code exceeds 32k.

I do not know why or how it can tell: 28682 bytes used
and on the other hand that the code exceeds 32k

The PBPL didn't convince me at all, not at all.... How could I proceed from here when not yet implemented all the calculation I need?

There is not so much calculations but this situation can not promise a future for PBPL in this project!

So, this is the reason why I try to come along with the 16bit PBP and not trusting the PBPL.....

I believe that it can be done somehow, by calculating small pieces at time, but I have not yet discovered how.... please help