BASIC assembler help

I’m stuck – LDR R2,[R12,#flags] is reporting “Bad address offset”.

R12 points to the start of my code and data.
flags is at relative address 290 decimal from the start.
This instruction is 33 words / 132 bytes further from the start of code, 422 bytes from start.
I thought offsets could be – 4095.

I tried moving the data section containing .flags to the start of the code, so the offset would be almost zero, and got the same error.

What am I doing wrong, or do I need to tackle this another way?

Hm…did you try inserting both the numbers you calculate by “hand” ? As 290 should be okay. But may be if you have “.flag” somewhere, the Basic assembler uses the address at “.flag”, which is may be “0×8000 + 290” …and that is of course invalid as not relative ? I often only hardcode the offsets from a base address in absolute values…if they are static…may be you post your code snippets so it becomes more clear

@EDIT: or it would be solved if you calculate it in your instruction like “LDR R2,[R12,#(flag – start_adress)]”

Put a flags% = 28 underneath countdown% = 24, make sure your .flags equd … is right after .countdown equd … and then do LDR R2,[R12,#flags%] — note the percent sign.

This is where I get confused.

 P%=address%
FOR pass%=0TO3STEP3
{OPT pass%
.flags EQUD 0
;
; more code and data
;
.init   ; called with address% in R12
       LDR r2,[R12,#flags]   ; this errors 
]

 P%=address%
flagoffset%=0
FOR pass%=0TO3STEP3
{OPT pass%
.flags EQUD 0
;
; more code and data
;
.init   ; called with address% in R12
       LDR r2,[R12,#flagoffset%]   ; this doesn't error 
]

I’m starting to see the problem – .flags is an address within the code, not an offset.
So in this case I want to load a register with the contents of memory a multiple of 8 bytes beyond flags, where the multiplier is in another register.
So if R0 contains 2, then shift it left by 3, is will now contain 16.
LDR R0,[R2,#flags] should work? No it won’t, because flags will be >4095. I need the large value in R2, and the small one in flags.
Getting address% into R2, and adding the 16 to it, I can then use LDR R0,[R2,#flags – address%]
THat looks as though I’m over-complicating it, but I can’t see how.

Put a flags% = 28 underneath countdown% = 24, make sure your .flags equd … is right after .countdown equd … and then do LDR R2,[R12,#flags%] — note the percent sign.

This sounds like something I tripped over the other day. I set up a BASIC variable which was going to be the address of an entry point, so i could use CALL init%.
init%=address% where the entry point was a jump at the start of the code.

I had b init at the start. It assembled as a branch to itself, or was interpreted as b init% instead. I changed the label to .initentry and used b initentry, which worked.

It seems the assembler will use a BASIC variable ending % and strip the % before using it, if that makes sense, so labels and BASIC variables should not have names differing only by the %.

What you’re doing with…

LDR r2,[R12,#flagoffset%]

…is essentially loading a word from the address that is comprised of “R12 + flagsoffset%”.

So in this case I want to load a register with the contents of memory a multiple of 8 bytes beyond flags, where the multiplier is in another register.

So… R12 is a base pointer and you want to load the word that is Rx multiples of eight bytes (or two words)?

Edit: Just read that you want to load so many words from “flags”. Well, in that case you want to set up the base pointer (the R12, or whatever) using ADR. See below.

How about LDR R2, [R12, Rx, LSL#3] ?

Which would be: R2 = load from (R12 + (Rx << 3)).

Edit: Explanation of ADR coming right up!

It’s also worth pointing out here that if you want to load a word from an address, you don’’t need to try to construct complicated methods, just use ADR if it’s within 4K, or ADRL if your setup supports it (I don’t think standard BASIC does). What ADR/ADRL does is get replaced by a PC-relative instruction (ADD or SUB) to construct a pointer from “here” to “there”.

So…

ADR  R2, word_to_load
LDR  R2, [R2]
...some code...
.word_to_load
DCD  &0

Of course, if you have multiple words there, you can then use offsets like [R2, #4] and [R2, #8] etc. Useful for accessing arrays.

This old document explains them all and also gives an example in C of what the different sort of memory accesses are doing: https://heyrick.eu/armwiki/LDR

Thanks Rick, helpful as usual

This old document explains them all and also gives an example in C of what the different sort of memory accesses are doing: https://heyrick.eu/armwiki/LDR

I’ve been making extensive use of this throughout, but sometimes I get “lost in a maze of twisty little addressing modes, all alike”.

How about LDR R2, [R12, Rx, LSL#3] ?

That looks like the version I need, but hadn’t discovered.

It’s all a long way from the Z80.

It’s all a long way from the Z80.

Ah, there’s your problem. Should have grown up with the 6502. 😋

Ah, there’s your problem. Should have grown up with the 6502

Well, I did write a 6502 disassembler in Fortran, and used it to extend the HP-IB bus functions in a Commodore Pet, which involved finding the ROM functions to drive and read the bus, and call then for extra capabilities.

I also wrote a terminal emulation ROM for the BBC, which involved hooking into the vectors for the serial buffer to allow a 2K byte buffer. We were working through serial over Ethernet devices, and they would return a complete Ethernet packet of data after “stop” had been asserted. It was interesting though that while all the BBC buffers were 256 bytes, the calls for size, freespace etc all returned 16-bit values. Very handy.

I still preferred the Z80 though – the ability to use the register pairs to access 16-bit addresses was far more comfortable than having to use page 0 addresses with a register offset.

So back on topic: I’ve now got the callback handler hooked in, and it works, at first. As your code example did, I’m setting a marker to say there’s one pending. All is well, until I clear that marker in the callback handler, at which point I get a series of on-screen errors and a lockup.

It does this if ALL that the handler does is to clear the marker and exit. If instead the handler writes a non-zero value, it doesn’t crash, so it’s the fact that the handler can be called a second time that’s causing the crash.

; this sets up a callback in each vector handler
        LDR      R1, [R12, #callbackpending%]  ; is one pending already?
        CMP      R1, #0
        LDMNEFD  R13!, {R0-R2, R12, PC}      ; callback already pending, so pass on the call
        ADR R0,callback             ; address OF callback code
        MOV R1,R12                  ; value TO pass in R12
        SWI XOS_AddCallBack         ; add the CALL
        MOV      R1, #1
        STR      R1, [R12, #callbackpending%]   ; flag callback waiting
;
;
DEF FNcallback
  [OPT pass%
  REM entered in SVC mode with interrupts enabled
  REM entered with R12 = base address
  REM must preserve all registers
.callback
         STMFD    R13!, {R0-R12, R14}

;;;         LDMFD    R13!, {R0-R12, PC} ; restore everything and pass on
;
     LDR R0,[R12,#savestatus%]   ; status, bit 0 is read, bit 1 is write
     MOV R1,#2                   ; CLEAR R1
     STR R1,[R12,#callbackpending%] ; allow another callback
; debug exit
; LDMFD    R13!, {R0-R12, PC} ; RESTORE everything AND pass ON
;
     ADR R1,palette_block        ; address of palette_block in R2
     SWI XWimp_ReadPalette       ; GET current settings
     BVS palette_read_error      ; catch the error
     ADR R0,colour_table         ; start OF COLOUR settings
     ADR R3,palette_block        ; palette data read
     LDR R1,[R12,#savestatus%]   ; GET the offset, 0,1,2 OR 3
     LDR R2,[R0, R1, LSR #4]     ; r0 offset by (R1 * 16)

Just noticed that this is wrong
     LDR R2,[R1, R0, LSR #4]     ; r1 offset by (R0 * 16)
Should be as here - I'll test this change now
Still crashes after I've changed all 3 of these
I think I need to rethink those ADDs as well. 

     STR R2,[R3,#68]             ; pointer COLOUR 1
     ADD R0,R0,#4                ; next colour entry
     LDR R2,[R0, R1, LSR #4]     ; r0 offset by (R1 * 16)
     STR R2,[R3,#72]             ; pointer COLOUR 2
     ADD R0,R0,#4                ; next colour entry
     LDR R2,[R0, R1, LSR #4]     ; r0 offset by (R1 * 16)
     STR R2,[R3,#76]             ; pointer COLOUR 3
     ADR R1,palette_block        ; address of palette_block in R2
     SWI XWimp_SetPalette        ; set new settings
     BVS palette_set_error       ; catch the ERROR

     LDMFD    R13!, {R0-R12, PC} ; restore everything and pass on

.palette_read_error
     ADR R0,read_message           ; GET the message
     SWI OS_GenerateError
.read_message
     EQUD   &400000FF                   ; &81F602
     EQUS   "Unable to read palette."
        EQUD   0       ; terminate string
        ALIGN
.palette_set_error
     ADR R0,read_message           ; GET the message
     SWI OS_GenerateError
.read_message
     EQUD   &400000FF                   ; &81F602
     EQUS   "Unable to set palette."
        EQUD   0       ; terminate string
        ALIGN

; format BB GG RR 00 or read as B0 G0 R0 00
.colour_table
    EQUD &F0F00000                 ; standard colour - blue
    EQUD &90900000                 ; dark blue
    EQUD &0000F000                 ; red - busy colour?
    EQUD 0                         ; padding so we can use offset of 16
    EQUD &00F00000                 ; green pointer; light green
    EQUD &00600000                 ; dark green
    EQUD &0000f000                 ; red NOT changed
    EQUD 0                         ; padding so we can use offset of 16
    EQUD &0000f000                 ; red pointer ; bright red
    EQUD &00009000                 ; dark red
    EQUD &0000f000                 ; red unchanged
    EQUD 0                         ; padding so we can use offset of 16
    EQUD &f000f000                 ; both pointer ; purple
    EQUD &90009000                 ; dark purple
    EQUD &0000F000                 ; red unchanged
.palette_block
]
REM create 20 word palette block
FORI%=1TO20
  [OPT pass%
  EQUD 0
  ]
NEXT
=""
:

So after checking the code, I have got this, which still crashes, with “Undefined instruction at” and an address starting FC. I can’t be more precise because that’s immediately followed by more errors, including “Filer may have gone wrong”.

 DEF FNcallback
  [OPT pass%
  REM entered in SVC mode with interrupts enabled
  REM entered with R12 = base address
  REM must preserve all registers
.callback
         STMFD    R13!, {R0-R12, R14}

;;;         LDMFD    R13!, {R0-R12, PC} ; restore everything and pass on
; will need check for pointer and / or hardware change

     MOV R1,#0                   ; CLEAR R1
     STR R1,[R12,#callbackpending%] ; allow another callback
     LDR R0,[R12,#savestatus%]   ; status, bit 0 is disc read, bit 1 is disc write
     ADR R1,palette_block        ; address of palette_block in R1
     SWI XWimp_ReadPalette       ; GET current settings
     BVS palette_read_error      ; catch the error
     ADR R0,colour_table         ; start OF COLOUR settings
     ADR R3,palette_block        ; address of palette_block in R3
     LDR R1,[R12,#savestatus%]   ; GET the offset, 0,1,2 OR 3
 ; at this POINT R0 points TO the table OF colours TO set FOR the pointer
 ;               R1 holds the offset number
 ;               R3 holds the address of the palette data, about to be changed
     LDR R2,[R0, R1, LSR #4]     ; r0 offset by (R1 * 16)
     STR R2,[R3,#68]             ; pointer COLOUR 1
     ADD R0,R0,#4                ; next colour entry - offset the base by 1 word
     LDR R2,[R0, R1, LSR #4]     ; r0 offset by (R1 * 16)
     STR R2,[R3,#72]             ; pointer COLOUR 2
     ADD R0,R0,#4                ; next colour entry
     LDR R2,[R0, R1, LSR #4]     ; r0 offset by (R1 * 16)
     STR R2,[R3,#76]             ; pointer COLOUR 3
     MOV R1,R3                   ; address of palette_block in R1 from R3
     SWI XWimp_SetPalette        ; set new settings
     BVS palette_set_error       ; catch the ERROR

     LDMFD    R13!, {R0-R12, PC} ; restore everything and pass on

.palette_read_error
     ADR R0,read_message           ; GET the message
     SWI OS_GenerateError
.read_message
     EQUD   &400000FF                   ; &81F602
     EQUS   "Unable to read palette."
        EQUD   0       ; terminate string
        ALIGN
.palette_set_error
     ADR R0,read_message           ; GET the message
     SWI OS_GenerateError
.read_message
     EQUD   &400000FF                   ; &81F602
     EQUS   "Unable to set palette."
        EQUD   0       ; terminate string
        ALIGN

; format BB GG RR 00 or read as B0 G0 R0 00
.colour_table
    EQUD &F0F00000                 ; standard colour - blue
    EQUD &90900000                 ; dark blue
    EQUD &0000F000                 ; red - busy colour?
    EQUD 0                         ; padding so we can use offset of 16
    EQUD &00F00000                 ; green pointer; light green
    EQUD &00600000                 ; dark green
    EQUD &0000f000                 ; red NOT changed
    EQUD 0                         ; padding so we can use offset of 16
    EQUD &0000f000                 ; red pointer ; bright red
    EQUD &00009000                 ; dark red
    EQUD &0000f000                 ; red unchanged
    EQUD 0                         ; padding so we can use offset of 16
    EQUD &f000f000                 ; both pointer ; purple
    EQUD &90009000                 ; dark purple
    EQUD &0000F000                 ; red unchanged
.palette_block
]
REM create 20 word palette block
FORI%=1TO20
  [OPT pass%
  EQUD 0
  ]
NEXT
=""

REM entered in SVC mode with interrupts enabled

How are you calling this code? Are you entering SVC mode yourself (SWI OS_EnterOS) or are you registering the function with an OS callback somewhere? In what memory are you assembling the code?

If you’re putting the code in application space and registering a callback beware that, unless you’re singletasking/outside the desktop, application space gets swapped out at Wimp_Poll. So you register &9234 as your callback handler but when it gets called another application is swapped in, and so &9234 in a different application gets called. There’s a high probability that what’s there isn’t valid instructions and so it takes the Undefined Instruction exception.

If you put the code in RMA or a dynamic area it should persist across applications being switched in and out.

How are you calling this code? Are you entering SVC mode yourself (SWI OS_EnterOS) or are you registering the function with an OS callback somewhere? In what memory are you assembling the code?

It’s registered using OS_AddCallBack, and the address is in RMA. The calling code is from two sources – one is TickerV, the other the common handler for 6 filing system vectors. There’s more detail in the Disc Activity Light thread. https://www.riscosopen.org/forum/forums/11/topics/16274?page=1

The memory is allocated thus: “XOS_Module”,6,,,size% ¸ ,,codespace%;flags%

The callback is registered like this

        LDR      R1, [R12, #callbackpending%]  ; is one pending already?
        CMP      R1, #0
        LDMNEFD  R13!, {R0-R2, R12, PC}      ; callback already pending, so pass on the call
        ADR R0,callback             ; address OF callback code
        MOV R1,R12                  ; value TO pass in R12
        SWI XOS_AddCallBack         ; add the CALL
        MOV      R1, #1
        STR      R1, [R12, #callbackpending%]   ; flag callback waiting

I’d be inclined to comment out all of the palette setting things and work on trying to get the callback mechanism working correctly. You can always plug more code in later. Start with the basic framework.

Additionally, I’m not sure you’ll want to be returning errors. Who or what are you passing the error up to?
It might be better to either fail silently, or (better but harder) set a flag that means “didn’t work, don’t bother any more”.

But that’s for later. We need the callback code working first.

BTW…

DEF FNcallback

   [OPT pass%

When and where is P% being set? Are you sure this is being assembled into the right place?
(Gah… Textile…)

I’d be inclined to comment out all of the palette setting things

I did try that. All the code did was stack the registers, set a value into the pending flag, and unstack the registers (into PC). If I set the flag to 0, meaning allow another callback, it crashed. If instead I set it to 2 for example, the callback was only called once and was fine.

I’ve just tested it again. With only one callback it’s fine.

Second callback – Internal error, abort on data transfer at &2000…. which is lower than the RMA block
Then a series of other aborts at different addresses. Alt-break offers to stop something, but the mouse and keyboard don’t respond. Control-break is the only thing that then works.

Edit: If I allow repeated callbacks but only from TickerV, it still crashes.
If instead I only allow repeated callbacks from vector_generic, it doesn’t crash.
Do I need to disable interrupts somewhere? I’m thinking the callback routine is maybe re-entering itself?

When and where is P% being set? Are you sure this is being assembled into the right place?

There’s only one assembly loop.
ADR R0,callback assembles to E28F00A4, and is at address 20CB836C

.callback is at address 20CB8418

E28F00A4 seems to be ADD PC,#164, which with the 8 byte offset on the PC looks right.

Who or what are you passing the error up to?

I was thinking it might get to the error handler of the BASIC calling program, or at least show up in Reporter. On reflection, I’m getting less certain about that.

I’ve put the whole thing here, in case any masochist wants a look.
http:/www.adamshome.org.uk/RiscOS/Blinker-broken.zip

On reflection, I’m getting less certain about that.

I think you’ll end up throwing an error at whatever happens to be the currently active task. ;-)

in case any masochist wants a look.

Ah. BASIC. My phone’s file viewer showed it to me in random Chinese. When I told it the correct character set, it was still gibberish. So… not tonight. I’m still whacked out from my lack of sleep on early Monday morning. https://heyrick.eu/blog/index.php?diary=20210315 [note: it’s really weird, even for me]

allow another callback, it crashed.

Have you compared the method with the one that I use?

I’m thinking the callback routine is maybe re-entering itself?

I suppose this might be possible if you’re responding to TickerV. I’d suggest that the setting the flag to allow another callback ought to be the very last thing that you do.

Just a thought… Where are you getting the value of R12 that you are using to set up the callback?

Have you compared the method with the one that I use?

It’s closely based on your code, and I keep going back to yours to cross-check. I’m missing something, but I don’t know what.

I suppose this might be possible if you’re responding to TickerV. I’d suggest that the setting the flag to allow another callback ought to be the very last thing that you do.

At the moment it’s the ONLY thing that routine does.

Just a thought… Where are you getting the value of R12 that you are using to set up the callback?

I pass in the base address in A5 to R0 when calling init, copy it to R12 and use it throughout. I keep looking at the code to see whether anything could alter it, but it’s only SWIs, and they are all documented as not going near R12. I suppose I could stack it at the start of the section, and unstack it when needed. Not tonight though.

The first error message usually (always?) lists an address starting &2000…. The code is assembled and loaded typically into 20CC….

it’s really weird, even for me]

I see what you mean. I generally wake up having a memory of having a strange dream, but I rarely remember any of it, or only tiny bits. I will call that a blessing then.

I had a look, there are two issues,

1. Your LDMNEFD R13!, {R0-R2, R12, PC} in vector_ticker_done isn’t balanced with the STMFD at the start of vector_ticker. Remove the R12.
2. If vector_ticker gets called in IRQ mode, the STMFD pushes R14_irq onto the stack, but when you do SWI XOS_AddCallBack this will corrupt R14_svc (i.e. the R14_svc of whatever code the ticker interrupted). So you need to save and restore R14_svc around your SWI.

Thanks Julie, no wonder I didn’t spot that.

However I’m struggling to save R14_svc – if I put that as the register to push,
the assembler reports “Missing } at line…”

Rick’s excelent wiki suggests adding ^ – however that doesn’t seem to work either.

However I’m struggling to save R14_svc – if I put that as the register to push,
the assembler reports “Missing } at line…”

It’s not a register, it’s R14 while in SVC mode.

I kind of suspect you might need to switch to SVC mode, stash the register, call the SWI, restore the register, then switch back to IRQ mode (because R13 depends upon mode!).
[hint: do not touch bit 4 of the PSR, it’ll blow up on ARMv8 if you do]

It’s fiddly. This is why I recommend people write stuff in C rather than assembler these days. ;-)

suggests adding ^

IIRC, that kind of works the other way around, allowing access to USR mode registers from a privileged mode.
(I say IIRC as it’s nothing I’ve ever found a need to do, so it’s one of those half remembered things)

I’ve added the following code, which I used in my other assembler project. I can’t tell whether it’s working here, because the BASIC assembler is now deciding to forget labels between the first and second pass. WTF is that about?
For example, this was called with FNswi(“XOS_AddCallBack”). The second pass the parameter was passed as "". Instead I created a BASIC string variable swi$ containing that and called FNswi(swi$) which worked on both passes.It’s losing others too, some held in BASIC variables, others dot-labels within the code. They are valid on the first pass. “no such variable” on the second. (Hmm, I think all the lost names started with lower-case c)

DEF FNswi(swi$)
REM it must NOT preserve the return registers from the SWI being called
REM it must pass back any flags from the SWI
REM the swi must be the X form
  *report swi$
REM  IF swi$="" THEN swi$ = "XOS_AddCallBack"
:
[OPT pass%
; R0-R12 are common to all modes except FIQ
                stmfd sp!, {R2-R12}      ; regs to be saved to irq mode stack
                mrs R10,cpsr             ; get current mode
                str r10,save_mode        ; save current mode
                bic r10,r10,#&1f         ; clear the mode bits
                orr r10,r10,#&13         ; switch to SVC mode
                msr cpsr_c,r10           ; change mode
                str r14,save_r14         ; save R14_svc in memory
                swi swi$                 ; call the swi
                ldr r14,save_r14         ; restore R14
                ldr r10,save_mode        ; get previous mode
                msr cpsr_c,R10           ; restore mode at entry. I hope this keeps the V flag from the swi
                ldmfd sp!, {R2-R12}      ; restore all all saved registers from irq mode stack
]
  ENDIF
=""

bic r10,r10,#&1f

BANG!

YOU’VE JUST BEEN ZAPPED BY ARMV8.
ALL YOUR BASE ARE BELONG TO US.

Seriously, don’t touch bit four.

Actually, nothing happens because you restore bit four before writing the register to CPSR rather than poking it directly. But it’s a good idea to get out of the habit of messing around with bit four (as we all do ;-) ).
You see, once upon a time bit 4 clear meant 26 bit modes, while bit 4 set meant 32 bit modes.
In ARMv8, bit four clear means 64 bit mode…only not only is that not how you change which ABI the processor is using, but 32 bit cannot promote itself to 64 bit anyway.

But all your base still belong to us, so nerr.

It’s fiddly. This is why I recommend people write stuff in C rather than assembler these days. ;-)

It’s one of numerous reasons why it’s better to write in C these days. I echo Rick’s recommendation.

It’s fiddly. This is why I recommend people write stuff in C rather than assembler these days.

and if my first A3000 came bundled with C I might have made the effort. And as it would have cost almost as much to buy as the computer did, that wasn’t reasonable.

I don’t know whether it’s changed, but at the time C was regarded as a “write-only language” because it was completely unreadable. Another reason why I stuck with BASIC.

Actually, nothing happens because you restore bit four before writing the register to CPSR rather than poking it directly.

I did check that after reading your previouspost and came to the same conclusion. I think it’s code I copied from somewhere, but I’ll update it.

Which still doesn’t explain why the assembler can’t remember labels between the first and second passes.

Edit: while holding on my doctor’s reception phone queue for 40 minutes, I’ve found that last problem at least – I was using BASIC functions to try and make the assembler more readable, but one of the functions wasn’t being referenced insode the FOR/NEXT loop. It didn’t error on the first pass as that was merely collecting definitions. On the second pass it hadn’t found the definition.

Meanwhile I’ve gone from 39th in the queue to 11th. Whoo-hoo! Last time I did this the call was disconnected by the phone provider after some time interval. We’ll see.