PBP and PBPL

[mackrackit]

I can not help much with the USB problem, but I would store my projects in a directory some place other than a sub directory of PBP. C:\projects woud be good. Most of my projects are on a flash drive or a SD card to make it easy to move from machine to machine.

When you have projects in the PBP ditectory and it comes time to upgrade them you will have to go find all of your "stuff" before it is deleted or over written during the new install.

[keymuu]

I can not help much with the USB problem, but I would store my projects in a directory some place other than a sub directory of PBP. C:\projects woud be good. Most of my projects are on a flash drive or a SD card to make it easy to move from machine to machine.

When you have projects in the PBP ditectory and it comes time to upgrade them you will have to go find all of your "stuff" before it is deleted or over written during the new install.

Thanks Dave!

Really interesting. What you said is of course true and logical.

I moved all from C:\PBP\Proj to C:\PBProj and compiled again I got rid of those four errors and instead I got "too many errors" meaning four Error[126] \PBP\PBPPI18.LIB 722 : argument out of range (34218 not between 0 and 32767) and that line in .LIB file is "CALL Label", and that drills me, does that mean Label is too far away or what? If this is true, how can one correct that? This brings me back almost to square one

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