Unnecessary Push/Pop

[britlion]

Not sure why the .asm ends up this way, but each time it pulls a parameter in a sub or function it seems to do this:

Code:

push hl
ld a, (ix+11)
pop hl

Why stack the HL register before loading the A register each time, and then unstack it immediately afterwards?

[boriel]

Not sure why the .asm ends up this way, but each time it pulls a parameter in a sub or function it seems to do this:

Code:

push hl
ld a, (ix+11)
pop hl

Why stack the HL register before loading the A register each time, and then unstack it immediately afterwards?

Where is that happening? I need more context information (E.g. put a function listing so I can generate the .asm code). -O3, by the way should remove this.

[britlion]

Straight to assembler, without O3 -

Code:

SUB pokethis(value as uByte)
poke @label+1,value
return

label:
asm
LD A,0 ; This will be poked.
end asm
END SUB

Turns the relevant part into:

Code:

_pokethis:
    push ix
    ld ix, 0
    add ix, sp
    ld hl, __LABEL__label
    inc hl
    push hl
    ld a, (ix+5)
    pop hl
    ld (hl), a
    jp _pokethis__leave
__LABEL__label:
#line 6
        LD A,00

With O3, it does certainly see the optimization, showing that the optimizer module is very impressive!:

Code:

_pokethis:
    push ix
    ld ix, 0
    add ix, sp
    ld hl, __LABEL__label
    inc hl
    ld a, (ix+5)
    ld (hl), a
    jp _pokethis__leave

The other thing that I'm curious about (as I noted in the other post, with this code in it), is that it doesn't load HL with [@label+1] - it loads it with @label, and then does inc HL. This isn't optimized by -O3.

[boriel]

Straight to assembler, without O3 -

Turns the relevant part into:

Code:

_pokethis:
    push ix
    ld ix, 0
    add ix, sp
    ld hl, __LABEL__label
    inc hl
    push hl
    ld a, (ix+5)
    pop hl
    ld (hl), a
    jp _pokethis__leave
__LABEL__label:
#line 6
        LD A,00

And it's OK:
POKE Expr1, Expr2 could be something like:

Code:

POKE 10, 2

or something very complicated like

Code:

POKE SIN(EXP(3*LN 52)) / RND * 72, RND *45 + USR "a" OR 1

both expressions are correct and must be allowed (or even more complicated ones). Since ZX have few registers and most of them 8 bits and many other limitations, a stack must be used to carry out math operations, etc. Thus the compiler calculates 1st expression, saves it in the stack (to free registers), calculates the 2nd, and recovers the 1st from the stack. No optimization can be done at this stage.

Optimization in the backend stage (pipeline, -O3) knows this (to some extent).

With O3, it does certainly see the optimization, showing that the optimizer module is very impressive!

;-) thx!

The other thing that I'm curious about (as I noted in the other post, with this code in it), is that it doesn't load HL with [@label+1] - it loads it with @label, and then does inc HL. This isn't optimized by -O3.

I'll answer that in the other topic, BTW, moved to Whislist forum.