CALL and local variables of in-line PASRM2

ke4pjw · 2022-02-03 16:10

Something is occurring that I simply do not understand with my inline PASM. When I CALL a routine in inline PASM, local variables previously setup are cleared upon RET from the routine.

Here is an example: The rx routine is within the inline PASM. The routine does not manipulate l_RX_RSR, but its value is $00000000 after RET from CALL. When I check the HUB values at rxptr, they are empty.

      mov l_RX_RSR,##$FFFF
      call #rx
      WRWORD rxptr,l_RX_RSR

Is this expected?

JonnyMac · 2022-02-03 16:23

You have D and S reversed in wrword -- this works.

pub test_pasm(p_word)  

  org
                mov       pr0, ##$FFFF
                call      #.rx
                wrword    pr0, p_word
                jmp       #.done

.rx             mov       pr1, #0
                ret

.done
  end

ke4pjw · 2022-02-03 16:27

I am an idiot. Bwhahahaha! Sorry. How embarrassing!

evanh · 2022-02-03 18:10

I've been caught out by that sort of thing lots. Switching between Spin and Pasm for the same routines usually trips me up. Sadly, most assemblers use a reverse notation for operand syntax. I blame Intel and M$ for that dominance.

Wuerfel_21 · 2022-02-03 18:32

Destination-on-the-right assembly syntax exists because otherwise the order for subtract/compare instructions would be confusing.

whicker · 2022-02-03 19:31

idle chat:
it's also funny that the most basic instruction "move" is actually "copy"

evanh · 2022-02-03 20:47

@Wuerfel_21 said:
Destination-on-the-right assembly syntax exists because otherwise the order for subtract/compare instructions would be confusing.

I assume you meant destination-on-the-left. Since SUB is the exception, it's a particularly poor reason. The real reason will be from formal maths. Reverse notation is the norm there.

Actually, there's nothing wrong with saying subtract R1 from R2 with result in R2 ... sub r1, r2
Or even result in r3 ... sub r1, r2, r3

CALL and local variables of in-line PASRM2

Comments