Reassigning I/O within the program ?

[tenaja]

Ah, yes, I'd forgotten about the tris part.

For what it is worth I also disagree. That almost sounds like the poster that says "I know my code is good so it has to be something else". 99% of the time the problem is the person on the keyboard. If you understand PBP and the understand the chip you are using PBP is very efficient.

Regarding your (plural) responses here, then we will respectfully disagree. For there to be "efficient" code, there must be something "inefficient" to compare it to. If you were to compare it to asm, then PBP is horrendous--as most compilers are, if the asm author knows his head from a hole in the ground. So that point is moot. However, if you compare it to a similar compiler, say, Proton, then PBP still only gets a "B" grade, which in my opinion is inefficient. In almost every instance I have compared, PBP is a minimum of 10% less efficient than Proton. In some instances, I've saved noticeably more.

The task in this simple topic here shows it:

PBP:

PinToChange        Var Byte
NewPinState        Var bit 

pintochange = 4
newpinstate = 1

PORTB.0[PinToChange] = NewPinState 
pintochange = 2
newpinstate = 0
PORTB.0[PinToChange] = NewPinState 

low PORTB.0
end     '74 words used

Proton:

PinToChange        Var Byte 
NewPinState        Var Bit  

pintochange = 4
newpinstate = 1
LoadBit PORTB, PinToChange, NewPinState

pintochange = 2
newpinstate = 0
LoadBit PORTB, PinToChange, NewPinState

Low PORTB.0
End     '67 words used

Just on this simplest of examples, PBP takes up more than 10% extra code space.

On top of that, I can actually EASILY see the generated asm code, and see where inefficiencies take place:

PROTON#CODE#START
        ORG 0
        GOTO PROTON#MAIN#START
A@BIT
        MOVWF 13
        ANDLW 248
        MOVWF 12
        RRF 12,F
        RRF 12,F
        RRF 12,W
        ADDWF 4,F
        CALL C@BT
        MOVWF 13
        ANDWF 0,W
        GOTO I@NT
C2@FB
        MOVF 13,W
        SKPC
        CLRW
        XORWF 0,W
        ANDWF 13,W
        XORWF 0,F
        GOTO I@NT
C@BT
        MOVLW (C@TBL >> 8)
        MOVWF 10
        MOVF 13,W
        ANDLW 7
        ADDWF 2,F
C@TBL
        RETLW 1
        RETLW 2
        RETLW 4
        RETLW 8
        RETLW 16
        RETLW 32
        RETLW 64
        RETLW 128
I@NT
        BCF 3,7
I@NT2
        BCF 3,5
        BCF 3,6
        RETURN
PROTON#MAIN#START
F2_SOF EQU $ ; TEST.PRP
F2_EOF EQU $ ; TEST.PRP
F1_SOF EQU $ ; TEST.BAS
F1_000012 EQU $ ; IN [TEST.BAS] PINTOCHANGE        VAR BYTE
F1_000013 EQU $ ; IN [TEST.BAS] NEWPINSTATE        VAR BIT
F1_000015 EQU $ ; IN [TEST.BAS] PINTOCHANGE = 4
        MOVLW 4
        MOVWF PINTOCHANGE
F1_000016 EQU $ ; IN [TEST.BAS] NEWPINSTATE = 1
        BSF _B#VR1,0
F1_000017 EQU $ ; IN [TEST.BAS] LOADBIT PORTB, PINTOCHANGE, NEWPINSTATE
        MOVLW PORTB
        MOVWF FSR
        MOVF PINTOCHANGE,W
        ADDLW 0
        CALL A@BIT
        BCF STATUS,0
        BTFSC _B#VR1,0
        BSF STATUS,0
        CALL C2@FB
F1_000019 EQU $ ; IN [TEST.BAS] PINTOCHANGE = 2
        MOVLW 2
        MOVWF PINTOCHANGE
F1_000020 EQU $ ; IN [TEST.BAS] NEWPINSTATE = 0
        BCF _B#VR1,0
F1_000021 EQU $ ; IN [TEST.BAS] LOADBIT PORTB, PINTOCHANGE, NEWPINSTATE
        MOVLW PORTB
        MOVWF FSR
        MOVF PINTOCHANGE,W
        ADDLW 0
        CALL A@BIT
        BCF STATUS,0
        BTFSC _B#VR1,0
        BSF STATUS,0
        CALL C2@FB
F1_000023 EQU $ ; IN [TEST.BAS] LOW PORTB.0
        BSF STATUS,5
RAM_BANK = 1
        BCF TRISB,0
        BCF STATUS,5
RAM_BANK = 0
        BCF PORTB,0
F1_000024 EQU $ ; IN [TEST.BAS] END
PB@LB2
        SLEEP
        GOTO PB@LB2
F1_EOF EQU $ ; TEST.BAS
PB@LB3
        GOTO PB@LB3

If I find a bottleneck that I need to speed up, I can count the words right there. If I want, I can recode it in basic, or copy/paste the asm and edit with my own optimizations.

See, my comments were directly related to the efficiency of the COMPILER. They had nothing to do with your coding or your abilities.

[mackrackit]

Then why do you even bother with PBP? Just stick with Proton.

[Darrel Taylor]

On top of that, I can actually EASILY see the generated asm code, and see where inefficiencies take place:

For the beniefit of those of us that don't use PROTON....
And since you only gave the ASM generated by PROTON...

Could you please explain the difference.
Relative to PINS and ARRAY's. And the ASM generated by PBP?

[tenaja]

Then why do you even bother with PBP? Just stick with Proton.

For the most part, I do. But I have PBP, and it's very similar to PDS in syntax (based on BS2), so I hang out here to learn and share.

For the beniefit of those of us that don't use PROTON....
And since you only gave the ASM generated by PROTON...

Could you please explain the difference.
Relative to PINS and ARRAY's. And the ASM generated by PBP?

ASM code for PBP?

	MOVE?CB	0C0h, ADCON0
	MOVE?CB	004h, _PinToChange
	MOVE?CT	001h, _NewPinState
	AIN?TTB	_NewPinState, _PORTB??0, _PinToChange
	MOVE?CB	002h, _PinToChange
	MOVE?CT	000h, _NewPinState
	AIN?TTB	_NewPinState, _PORTB??0, _PinToChange
	LOW?T	_PORTB??0
	END?

Hardly indicative of the amount of code space used...
You actually have to use the LST file. I'll post it later...