News:

Let's find out together what makes a PIC Tick!

Main Menu

Trying to understand the code generated

Started by TimB, Aug 19, 2021, 08:16 PM

Previous topic - Next topic

TimB

Hi,

This may be a post more suited to Les.

I'm coding for a Pic16f1779 Its a only because they were in stock and I needed 20 off

I added some code and decided to just check what the asm looked like

It was not what I expected
It seems way more complex that I would have thought was needed
Know doubt there is a reason for it to be so verbose but I cannot think why.

F1_000453 equ $ ; in [SQ2E 16F1393 VER3.BAS] Inc aFanFailCounter[2]
    movlb 0X01
    movf aFanFailCounter#2,W
    movlb 0x00
    movwf PBS_VAR0
    incf PBS_VAR0,F
    movf PBS_VAR0,W
    movlb 0X01
    movwf aFanFailCounter#2
    movlb 0x00
    bra _lbl__27
_lbl__26

top204

#1
Some of the extra mnemonics are because of the very fragmented RAM in the, so called, enhanced 14-bit core devices, and that the command is seeing an array, but cannot see the element type th earray is using. So as can be seen by the Movlb mnemonics, the array is outside of RAM bank 0, but the compiler's sysem variable are always inside RAM bank 0, and the parser is calling the, general, array element extract function, so it places the result in a system variable, then increments that, then places it back into the array.

Try using: "Inc aFanFailCounter#2", then the compiler knows where the element's variable actually is in RAM, and what type it is, and does not treat it as a, general, array that could have a variable as its index. The compiler will then generate the code:

movlb 0X01
incf aFanFailCounter#20,F