Move seperate bytes into a word

[Darrel Taylor]

Technically, it uses less RAM.

A statement like z=a+b<<4+c<<8+d<<12

Will create 3 T variables to hold the intermediate results.
Each T var is a Word (Long for PBPL), so it uses at least 6 more bytes of RAM.
Of course, if the program already had T vars from other statements, it won't make any difference.

For Flash, it uses 6-8 words depending on variable locations.
z=a+b<<4+c<<8+d<<12, uses ~60 depending on library routines already used.

And Time wise, it takes about 6-8 uS @ 4Mhz
z=a+b<<4+c<<8+d<<12, uses several hundred.
<br>

[Ioannis]

OK, that was not fair Darrel!

Cannot beat ASM code of course.

If I wanted to do that way, how can one find what this CHK?RP does? Where does this come from? I suppose there is no RTFM on this. Maybe digging deep inside PBP's librarys?

Ioannis

[Bruce]

OK - here's a little smaller verion...;o}

Z VAR WORD BANK0 ; use BANKA for 18F part
A VAR Z.LowByte
B VAR BYTE BANK0
C VAR Z.HighByte
D VAR BYTE BANK0

A=%00000001
B=%00000010
C=%00000011
D=%00000100

ASM
    CHK?RP _Z
    swapf  _B, W     ; swap nibbles in B, result in W
    iorwf  _A, F     ; or with A, result in A (low byte is done)
    swapf  _D, W     ; swap nibbles in D, result in W
    iorwf  _C, F     ; or with C, result in C (HighByte is done)
ENDASM

Z = %0100 0011 0010 0001

[Jerson]

Wow! What compact and fast code! Both Bruce and DT must have been coding in Assembler for ages to have such skill I might have coded it like Steve(mister_e) here and just got the job done. But, I guess, this is how compiler writers optimize their code generation capabilities. I would like to hazard a thought that this kind of optimisations would help PBP generate tighter code.

[Darrel Taylor]

That's why we don't have optimization contests for money around here...

Bruce would always win.

SWEET!<hr>

Ioannis,

The CHK?RP macro just changes the bank to where the specified variable is located. That way you don't have to keep track of where everything is. You can let PBP handle the banking, even though it's ASM.

And yup, wading through the library is about the only RTFM.
It's in the PBPPIC14.lib file for the 12F and 16F's.

[Ioannis]

Thanks Darrel. But if the macro had to change the page, how will it restore backe the original page? It isn't called again. Is this done automatically?

Ioannis

[mister_e]

PBP will handle it for you on the next PBP command.

[Darrel Taylor]

There is another macro that resets it to bank0 ...

    RST?RP   ' Reset to Bank0

The ASM statement uses that macro to set the bank to 0.
So when you enter an ASM block, you always know you're starting off in bank0.

The ENDASM does not reset to bank0, but as long as you use PBP's banking system and don't change it manually, then after you exit the ASM block, PBP knows what bank you changed to, and will be able to continue on.

If you do GOTO's or BRA's in the ASM block, you have to be more careful, because PBP's banking system can't follow the jumps. It's up to you to make sure the banks are correct before jumping.

If the banks are changed manually without PBP's assistance, then you have to reset the bank manually before exiting the ASM block.

    banksel 0
PREVBANK = 0
ENDASM

hth,