Re: [MiNT] libgem16: vs_color

["Roger Burrows" <rfburrows@ymail.com>]

On 18 Jan 2010 at 11:29, Helmut Karlowski wrote:

> Am 18.01.2010, 10:44 Uhr, schrieb Vincent Rivière  
> <vincent.riviere@freesbee.fr>:
> 
> > But it is strange, the bug appears before the trap.
> > There is only standard C here, and nothing can be inlined...
> 
> Yeah - really strange: everything is on the stack, and should be separated  
>  from each other.
> 
> > I think the explication will become obvious by looking at the generated  
> > assembler code.
> 
> This is without the static:
> 
OK, I can't read that strange assembly syntax, so I changed it to standard 
Motorola format (compared the disaasembly to make sure I did it right) and 
commented it.  Here it is:
;
; disassembly from helmut, converted to Motorola syntax
; and commented by roger burrows
;
_vs_color:
        lea     -64(sp),sp              ;make space for 64 bytes on stack
        move.l  d2,-(sp)                ;save d2
;
;stack layout at this point:
;       +0      saved d2
;       +4      ?
;       +6      vdi_intin
;       +14     VDIPB
;       +34     vdi_control
;       +64     ?
;       +68     return address
;       +72     passed param: handle
;       +74     passed param: colour
;       +76     passed param: -> rgb array
;
        move.w  72(sp),d2               ;d2.w = handle
        move.w  74(sp),d0               ;d0.w = colour
        movea.l 76(sp),a0               ;a0 ->rgb array
        clr.l   34(sp)                  ;clear vdi_control to zeros
        clr.l   38(sp)
        clr.l   42(sp)
        clr.l   46(sp)
        clr.l   50(sp)
        clr.l   54(sp)
        clr.l   58(sp)
        clr.w   62(sp)
        clr.l   6(sp)                   ;clear vdi_intin to zeroes
        clr.l   10(sp)
        lea     34(sp),a1               ;now we set up vdipb
        move.l  a1,14(sp)               ;store ptr to vdi_control
        lea     6(sp),a1
        move.l  a1,18(sp)               ;store ptr to vdi_intin
        clr.l   22(sp)                  ;set vdi_ptsin to null
        move.l  #0,26(sp)               ;set vdi_intout to null
        move.l  #0,30(sp)               ;set vdi_ptsout to null
        move.w  d0,6(sp)                ;vdi_intin[0] = colour
        move.w  (a0)+,8(sp)             ;vdi_intin[1] = rgb[0]	***
        move.w  (a0)+,10(sp)            ;vdi_intin[2] = rgb[1]
        move.w  (a0),12(sp)             ;vdi_intin[3] = rgb[2]
        lea     14(sp),a1               ;a1 -> vdipb
        movea.l a1,a0                   ;a0 -> vdipb
        move.l  a0,d1                   ;d1 -> vdipb
        movea.l (a0),a0                 ;a0 -> vdi_control
        move.l  #$000e0000,(a0)+        ;vdi_control[0] = $000e
                                        ;vdi_control[1] = 0
        move.l  #4,(a0)+                ;vdi_control[2] = 0
                                        ;vdi_control[3] = 4
        move.l  #0,(a0)+                ;vdi_control[4] = 0
                                        ;vdi_control[5] = 0
        move.w  d2,(a0)                 ;vdi_control[6] = handle
        move.w  #115,d0                 ;call vdi
        trap    #2
        move.l  (sp)+,d2                ;restore d2
        lea     64(sp),sp               ;fix up stack
        rts
        end

I've looked carefully, and I can't see anything wrong (apart from efficiency) 
with the generated code.

> 
> The bug appears at 62. I'm not very good at assembler though.
> 
I've marked it with ***.  Nothing wrong there.  a0 was copied from the arg list 
and unchanged to that point.  

It doesn't seem possible - within the code itself - for the problem to occur.  
If it is happening between the start of vs_color() and the issuing of the trap, 
then I see two possibilities:
	a) the code itself is being clobbered before execution
	b) an interrupt is occurring which fails to save all the registers.

(a) should be easy to check.  To see if (b) is the problem, write your own 
vs_color() which disables interrupts before doing anything, then re-enables 
them just before the trap.

I have to say, though, that I suspect that the problem isn't here, no matter 
how much it might look that way ...

Roger Burrows