PBP 2.50 pbpw vs pbpl .exe

[Darrel Taylor]

Surprise!

Well, credit were credit is due.
The workaround was from Charles Leo @ melabs.

But like the other thread said. That is what I'm doing now.
<br>

[HenrikOlsson]

Man, I got to learn how to spell. S-U-R-P-R-I-S-E

Thanks then to Charles and to you Darrel.

/Henrik.

[Archangel]

Surprise!

Well, credit were credit is due.
The workaround was from Charles Leo @ melabs.

But like the other thread said. That is what I'm doing now.
<br>

Thanks Henrik, and Darrel,
So I guess the next logical question is . . . why not use only the renamed PBPL ? And I guess this is my fault, you see I just bought the MCS pro about a month ago . . .
<p>
EDIT: Ahhhh only 18XXXX chips supported by PBPL

[Darrel Taylor]

So I guess the next logical question is . . . why not use only the renamed PBPL ?

Mostly because some things work just a little differently than they used to.

Programs that you've written before, may compile fine with the new version, but may not work exactly the way it would if compiled with the 16-bit version (PBPW.EXE).

Sometimes it's just little things, like MAX and MIN, or math formulas that you expect to have one result after Overflowing, but it doesn't overflow anymore. Or maybe an IF statement that didn't consider negative numbers when it was first written.

So for anything written for 2.47 or prior, it's a good idea to compile it with PBPW.EXE (2.50)

And if you want to use longs. Make a new program. If you just try to insert longs in your old programs ... well I guess at least we'll have lots of problems to talk about on the forum .

The other part is that PBPL.EXE will generate programs that are larger than PBPW. Most of the System Functions are set up to use LONG variables. Even if you don't use LONGs in your program, it still takes up the extra code space. Plus all T? variables (the temporary variables use in complex math formulas) are all LONGs, as are R0-R3, so it uses more RAM too.

Charles Linquis recently reported that his program which used to fit in 128k, doesn't anymore.
What a Code HOG.

He also estimated the increased size at 5%.
Seems pretty low to me. I would have expected more.

Then there's that 18F only problem that you pointed out.

<br>

[Archangel]

Thanks Darrel,
for clearing that up, so if you do not use 18f series chips you might just as well save your money on the upgrade, Huh ? Cause LONGs do not beLONG in a 16Fxxx. Any real changes in ver 2.5 that do work on the poor relatives ?

[Darrel Taylor]

Any real changes in ver 2.5 that do work on the poor relatives ?

Hmmm, good question!

I don't know. Haven't even looked.

Not sure I'll even use 16F's anymore.
At least until there's PBPPI14L.LIB and MAC
<br>

[SteveB]

He also estimated the increased size at 5%.
Seems pretty low to me. I would have expected more.

Probably because as a percentage of a very large program, the extra code is not much. For a small bit of code, it certinaly is more. Just a quick check I did turned 2174 bytes into 2818. About 30%

SteveB

[Darrel Taylor]

Good point steve!

Percentages kind of work that way, don't they?

But when you point out it's only 644 bytes extra, it most certainly seems worth it.
<br>

[SteveB]

... it's only 644 bytes extra...

That was without actually adding any additional code or changing variables. Just recompiling an existing bit of code with the PBPL.

I would guess there is a little bit more added as code is introduced, but it does give an idea of the minimum overhead cost.