Native ARM Co Pro: *BAS135 CLOCKSP throws an exception

[hoglet67]

Data Abort at 0001C1B8
Registers:
r[00]=00008F00
r[01]=001FF19E
r[02]=00000010
r[03]=00000010
r[04]=00000A3A
r[05]=001FFBD8
r[06]=000000FF
r[07]=001FFBD6
r[08]=00008700
r[09]=00000002
r[10]=00200000
r[11]=01F44098
r[12]=00008100
r[14]=0001C1C0
Memory:
0001C1A8=E2112003
0001C1AC=0A000009
0001C1B0=E1A02182
0001C1B4=E2623020
0001C1B8=E89100C0 <<<<<<
0001C1BC=E1A06236
0001C1C0=E1866317
0001C1C4=E4806004
0001C1C8=E2811004
Flags:
NZCV--------------------IFTMMMMM
00100000000000000000000100010000 (User Mode)
Halted waiting for reset

[hoglet67]

This is happening here (s.Command):

LOADFILETOKENCOPY
        LDR     R0,[ARGP,#PAGE]
        ANDS    R2,R1,#3               ;word mask
        BEQ     LOADFILEFCOPYALIGN
        MOV     R2,R2,LSL #3
        RSB     R3,R2,#32
LOADFILEFCOPYMIS
;        BIC     R6,R1,#3
;        LDMIA   R6,{R6,R7}
        LDMIA   R1,{R6,R7}

There is an alignment problem with R1: 001FF19E

That address is where the basic program has been loaded, and is calculated here:

LOADFILEFINAL
        MOV     R0,#5
        ADD     R1,ARGP,#STRACC
        SWI     FILE
        SUB     R7,SP,#1024
        CMP     R0,#1
        SUBEQ   R7,R7,R4
        LDR     R2,[ARGP,#PAGE]
        ADD     R2,R2,#256             ;if getting tight on memory, don't want to leave too much
        CMP     R2,R7
        MOVCS   R7,R2
        MOV     R2,R7
        MOV     R3,#0
        MOV     R0,#&FF
        SWI     FILE

i.e. the address seems to be SP - 1024 - length of program

I don't really understand what's going on here, and why the load address is on the stack, rather than at page. I would have thought the behaviour would be the same as doing CHAIN from the command line after basic had started.

[jgharston]

At that point the code is doing a memory copy from an unaligned address (as shown in the debug showing R1=xxx9E). The destination is always aligned starting at PAGE (eg &8F00), if the source is also align the code skips forward to do a fast LDR R7,[R1],#4:STR R7,[R0],#4 loop. The code shown is used where the source is misaligned (hint from label LOADFILEFCOPYMIS) and the following code aligns the data that has been read:
LDMIA R1,{R6,R7} ; load misaligned word
MOV R6,R6,LSR R2 ; correct for misalignement
ORR R6,R6,R7,LSL R3 ; correct for misalignement
STR R6,[R0],#4 ; store word which is now aligned

You don't get the same behaviour with CHAIN as CHAIN always loads to PAGE. Loading from the command line does both LOAD and TEXTLOAD according to the contents of the loaded file, so has to temporarily load the file elsewhere to examine it before deciding if it is text and needed tokenising or is already tokenised and needs to just be chucked over to PAGE. So it loads it to the stack. What it really should do is have a BIC #3 after the SUB R7,SP,#1024 to ensure the address on the stack is aligned.

[hoglet67]

So is this issue down to a difference between the original ARM allowing LDM from a mis-aligned address and the later ARM on the Pi 3 not?

Let me check that un-aligned accesses are enabled (this is an config register option)

[jgharston]

"What it really should do is have a BIC #3 after the SUB R7,SP,#1024 to ensure the address on the stack is aligned."

I was pondering this as drifting off to sleep (that seems to be the way I debug code), and I think even with that it would still have nonaligned transfers as the detokenising code is also called if you enter BASIC with an in-core text file, so it would happen if the user did, eg, *BASIC @00043231,000437DF

[hoglet67]

This seems to have fixed it:

Original version:

 LOADFILEFCOPYMIS
        LDMIA   R1,{R6,R7} 

Fixed version:

 LOADFILEFCOPYMIS
        BIC     R6,R1,#3
        LDMIA   R6,{R6,R7}

The fix was already in the code, just commented out.

[hoglet67]

This also fixes is, which I think is probably better:

        MOV     R0,#5
        ADD     R1,ARGP,#STRACC
        SWI     FILE
        SUB     R7,SP,#1024
        CMP     R0,#1
        SUBEQ   R7,R7,R4
        BIC     R7,R7,#3               ; <<<<<< Fixes #37
        LDR     R2,[ARGP,#PAGE]
        ADD     R2,R2,#256             ; if getting tight on memory, don't want to leave too much
        CMP     R2,R7
        MOVCS   R7,R2
        MOV     R2,R7
        MOV     R3,#0
        MOV     R0,#&FF
        SWI     FILE

(I think this is what JGH originally suggested)

[hoglet67]

Fixed in gecko-dev (used the second version of the fix)