OS_Claim (0x1F)

THIS HAS BUGS that I can’t be bothered sorting out right now.

This assembles as a MODULE (not an AIF).

CODE REMOVED – CORRECTED VERSION FURTHER DOWN THE THREAD

Some observations from the original:

mov r0, #6 ; IOC Timer 1 or Device identifier provided by HAL_TimerDevice???

I’m guessing HAL_TimerDevice. This is rather unclear, isn’t it?

mov r1, #0×01000000 ; Timer period

If you want a once per second tick, then &1000000 is not the way to do it. That’s 16,777,216 (or just under 17 seconds).

mov r8, #0 ; Call HAL routine
mov r9, #113 ; HAL_TimerIRQClear
SWI “OS_Hardware”

Your machine will stiff. You are trashing R8 and R9 and you are calling SWIs in IRQ mode without first having saved R14_svc (so SWI call will drop to SVC mode and corrupt whatever R14_svc was).
Also, you are not calling X form SWIs so… who or what is going to handle errors?
Did you read the interrupt handling chapter of the PRM?

enumerate_list

…and a lot of stuff incorrectly copied from Rik’s HALTimer module which will be trying to restore your machine to a state that you never set up (assuming it doesn’t crash before then, that is).

Remember – the reason that people think assembler is scary is because there is zero leeway for errors. Anything that assembles is accepted, whether or not it actually works is an entirely different question! ;-)

If you can, you might be better off using Rik’s HALTimer module, for two reasons. Firstly, somebody else has pulled their hair out on our behalf. We don’t need to do this, a solution already exists. To this end, unless I have an itch that needs scratching, I’m not going to spend time looking to see what is wrong with my module code. Me? I’d just use HALTimer…
And secondly, RISC OS is not blessed with an abundance of timers. If I was to load my module after your program, I’d stomp on the timer and claim it as my own (and vice versa). With something like HALTimer, a generic resource provider should be able to support multiple clients without each of them fighting over the one timer that is available.

Hi Rick
Thank you very very much for your effort and support.
I’m reading the PRM (Module section) and working to make my code run.

Quick note – just noticed a bug.

     ; If not, claim some workspace
     MOV     R0, #RMAClaim
     MOV     R3, #32               ; 32 bytes
     SWI     XOS_Memory
     LDRVS   PC, [R13], #4

That last line should be:

     LDMVSFD R13!, {R6-R9, PC}

The first version I wrote only stacked R14. The code was updated to be correct (preserve R6-R9 as well) but this one was missed… in the unlikely event that RISC OS can’t find 32 bytes somewhere in the RMA…

[the original has been corrected]

Jeffrey: Just thinking aloud… After the MSRs to change mode (in the IRQ handler), should there be a NOP afterwards like old ARMs or is this no longer an issue?

Rick, I may be wrong, you are a better man than me but I think the stack goes all wrong at BL oh_crap_jumpin. Its been many years since I’ve done modules but I think you can leak the workspace if you fail to start in some places. If I’m wrong please forgive me.

After the MSRs to change mode (in the IRQ handler), should there be a NOP afterwards like old ARMs or is this no longer an issue?

That was the StrongARM bug was it not? instruction after the MSR actioned twice so stuff in a protective NOP

Plenty of instances of no NOP littered through the CVS (not least the macros)

but I think you can leak the workspace if you fail to start in some places

Yes. If you drop out at the point of failing to set the vector claim, it will not release the workspace claim. I thought about sorting that out, but since I was just making an example to see if it worked at all, I didn’t bother. It isn’t a finished or bug free module. ;-)

That was the StrongARM bug was it not? instruction after the MSR actioned twice so stuff in a protective NOP

I was also thinking of the ARM2/3(+?) issue where TEQP and the like needed a NOP between changing mode and accessing banked registers. If you see from the code, the first mode change (IRQ→SVC) immediately stacks R14. Both R13 and R14 are private to SVC mode. After the second mode change (back to IRQ), the registers are retrieved from R13 (private to IRQ mode).

Yes. If you drop out at the point of failing to set the vector claim, it will not release the workspace claim.

Definitely no expert but isn’t there some tidy up call that clears those things up?
Ah, RMTidy – deprecated, doesn’t do anything.

I was also thinking of the ARM2/3(+?) issue where TEQP and the like needed a NOP between changing mode and accessing banked registers.

Yes, sort of:

1. The comments in code speak of allowing registers to settle. ??
2. You’re using the HAL Timer – how many ARM 2/3 systems have a HAL?

Definitely no expert but isn’t there some tidy up call that clears those things up?

I think a module, when it is quit, the OS can release claimed workspace automatically. I haven’t looked in the code so I don’t know if this happens when a module fails to initialise.

The comments in code speak of allowing registers to settle. ??

Yes – banked registers were not “safe” to access immediately after a mode change. Possibly a pipeline issue? I don’t know.

You’re using the HAL Timer – how many ARM 2/3 systems have a HAL?

The question wasn’t referring to the presence of the HAL on older processors, the question was that as it was not safe to use banked registers immediately after a mode change on ARM2/3, and there was an issue with MSR on StrongARM – is it “okay” to do this on current ARMs or should a NOP be used still?
The PDF ARM ARM doesn’t mention anything (it doesn’t mention TEQP either! hehe!), but then it doesn’t seem to make reference to “tricky” code sequences at all (this might be more processor specific?). The ARM System Designer’s Guide implies that this is no longer an issue (code examples on p332 and p339). So, I’ll assume it is okay to do this on modern ARM. ;-)

Thanks Rick for the example code – still looking for what goes in R3/4 in OS_claimDeviceVector r0=13 expansion card interrupt – any ideas?

Doing a bvs xxx if OS_Module 6 couldn’t claim any memory might be better – it’s a pity the assembler couldn’t give a warning if the stmfd and ldmfd don’t match.
Perhaps if one’s code only had one entry and exit – it might be easier to check.

Also note that the GCC’s assembler/linker is near enough the same as ObjAsm – for use by one’s who can’t obtain ObjAsm for what ever reason.

Might attract some younger potential coders :-)

By the way what is the difference between TSTP PC,#0 and TEQP PC,#0 ?

still looking for what goes in R3/4 in OS_claimDeviceVector r0=13 expansion card interrupt – any ideas?

https://www.riscosopen.org/wiki/documentation/show/OS_ClaimDeviceVector

Doing a bvs xxx if OS_Module 6 couldn’t claim any memory might be better

BVS to where? If it can’t claim workspace, the only thing we can do is bomb out.

it’s a pity the assembler couldn’t give a warning if the stmfd and ldmfd don’t match.

The RISC OS source uses “ENTRY” and “EXIT” (if I remember correctly). This was just an oversight as the original code only stacked R14.

Perhaps if one’s code only had one entry and exit – it might be easier to check.

I absolutely do not subscribe to that theory. I believe that a function should do what it is supposed to do and exit as soon as it has done all that it can.

By the way what is the difference between TSTP PC,#0 and TEQP PC,#0 ?

TSTP will AND the value into the status register while TEQP will EOR the value (IIRC). This is old-style 26 bit stuff, probably ought to be forgotten these days. ;-)

Hi Rick,
Just two things:

1º To claim some workspace you use OS_Memory. I’ve been reading the manual and OS_Memory doesn’t use R3 to claim memory. Could it be OS_Module instead? Do you claim 32 bytes for a specific reason?

This is how I create my workspace:

2º Is there a way to use gcc to generate Modules in assembly rather than in C? I’m using BASIC for the moment, but gcc is better for me.

To claim some workspace you use OS_Memory.

Gah! <epic embarrassed!>

Maybe that’s why it doesn’t work? ;-)

Do you claim 32 bytes for a specific reason?

Four bytes for the counter, four bytes for the IRQ number, and the rest as workspace for building the numerical string in ConvertCardinal.

Can’t help re. GCC. But I’m kinda wishing right now that objasm had a dumbass filter to reject stupid code. :-P

Like I said. Assembler is scary because anything that is a valid instruction will assemble. Whether or not it makes any sense is an entirely different thing……….

Hi Rick,
Other two questions :S

1º I have adapted my code to BASIC. I load it and I see it in the list of ‘*MODULES’.
When I use ‘*Counter’ it generates an abort in ‘MOV R2, #24’ (before OS_ConvertCardinal). Do you get the same error?

2º I’ve changed the BASIC file which generates the Module, but when I load it, I receive the same previous abort. Does ‘*RMKill’ delete the workspace like the Module or just the Module? How do I delete the Workspace?

Thank you :)

No, *TCV didn’t crash on me.

A data abort, right? Check what R12 is pointing to. Did you push it back after the allocation at the beginning? [you did change that to OS_Module right? calling OS_Memory was an error]
The reason I say this is because, due to the pipeline, the instruction that faulted is two instructions before the one reported, so it’s the LDR R0, [R12, #Counter] that is failing. Did you do the previous LDR R12, [R12]?

RMKill should release the workspace as it calls the module’s exit handler (the finalise entry). If not, RISC OS will deallocate the claim itself. Read PRM 1-209, Modules → Workspace.

Ummm. I just load the Module that has been created, and use the * Counter. I’m checking if I need something else (*RMTidy, for example).

If *RMKill deletes the workspace, there’s something weird happening to me. As soon as I loaded the first Module, I deleted it to change something of the code. Then I loaded another Module again, but it’s still generating the same error, in the same address. If I *MEMORYI that address, I see the code of the previous Module.

If I *MEMORYI that address, I see the code of the previous Module.

Yes, I noticed that. I think there is a bug in RISC OS that when a module messes up releasing itself, it becomes a sort of “zombie” and reloading a fixed module will revert to the original. There was a “%” in the title, so maybe RISC OS thought it was an incarnation dying, not the entire module itself?
More fun was when *TCV worked (and crashed, nothing sensible for R12) yet the module did not exist in the module list (nor did asking for help on TCV work). Uhhh… ;-)

This bugged me (plus a large helping of embarrassment from mixing up OS_Module and OS_Memory – duh) so I thought I’d take another crack at it.
I have deleted the earlier code (previous message) and pointed people at this version.

This time:

• The exits are handled more gracefully than before
• Less weirdness in the init fail exits
• Provides some sort of error message instead of bombing (assumes X SWIs return a valid error)
• Reads timer granularity so will set a 1-sec tick regardless of what the timer rate actually is
• Does not disable device IRQs on exit if something else was using them (API fail? – what if the other user exits meanwhile?)
• Loads, runs, exits correctly – kinda like it was supposed to the first time around

In my defence, I put the original together in about 40 minutes. This time, I took a bit longer on the revisions, and more importantly, consumed two mugs of tea in the process. That’s the difference. ;-)

It is running right now, results in a TaskWindow, via:

REPEAT : OSCLI("TCV") : WAIT : WAIT : UNTIL 0

Okay then.
Here’s the code:

; HALtimer.s.adrian <-- take two ;-)
; Conversion of forum post into objasm format
; ( but it has been mostly rewritten! ;-) )


     GET     ^.h.SWINames

; Workspace offsets
Counter          * 0               ; Current value of counter (increments)
TimerIRQ         * 4               ; Which IRQ is Timer1 on?
Granularity      * 8               ; Number of ticks per second (Timer1)
IRQwasAlreadyOn  * 12              ; Non-zero if device IRQ was already on
Workspace        * 16              ; String buffer for OS_ConvertCardinal4

; RMA workspace
RMAClaim         * 6
RMAFree          * 7

; OS_Hardware call stuff (refer to HAL API on ROOL site)
CallHAL          * 0
IRQEnable        * 1
IRQDisable       * 2
IRQClear         * 3
Timers           * 12
TimerDevice      * 13
TimerGranularity * 14
TimerSetPeriod   * 16
TimerIRQClear    * 113


     AREA    |HAL$Timer$Code|, CODE, DATA, A32bit
     ENTRY

entry
     ; Generic module initialisation
     DCD     0                     ; Start
     DCD     (initialise - entry)  ; Initialise
     DCD     (finalise - entry)    ; Finalise
     DCD     0                     ; Service Call
     DCD     (titlestring - entry) ; Module title
     DCD     (helpstring - entry)  ; Module help
     DCD     (commandtable - entry); Command table
     DCD     0                     ; SWI chunk
     DCD     0                     ; SWI handler
     DCD     0                     ; SWI decoding table
     DCD     0                     ; SWI decoding code
     DCD     0                     ; Messages file
     DCD     (thirtytwo - entry)   ; 32bit flag

titlestring
     =       "HAL_timer_test", 0
     ALIGN

helpstring
     =       "HAL_timer_test", 9, "0.02 (29 Dec 2014) by Rick Murray for Adrian", 0
     ALIGN

thirtytwo
     DCD     1


; =======================================
initialise
     ; Module initialise - can trash R0-R6 and R12.
     ; Return with V set if module failed to start.
     ; Entry stacks R6-R9,R14. Exit pulls.

     STMFD   R13!, {R6-R9, R14}

     ; How many timers are available?
     MOV     R8, #CallHAL
     MOV     R9, #Timers
     SWI     XOS_Hardware
     ADRVS   R0, error_nohal       ; Bomb out if no HAL or HAL call fails
     LDMVSFD R13!, {R6-R9, PC}

     CMP     R0, #2                ; Must have at least two timers
     BGE     init_continue         ; Branch if so, else...
     ADR     R0, error_notimer     ; ...throw an error
     MSR     CPSR_f, #(1 :SHL: 28) ; set V bit
     LDMFD   R13!, {R6-R9, PC}

init_continue
     ; Read IRQ number of Timer1 (Timer0 is reserved for RISC OS's use)
     MOV     R0, #1
     MOV     R8, #CallHAL
     MOV     R9, #TimerDevice
     SWI     XOS_Hardware
     ADRVS   R0, error_nohal
     LDMVSFD R13!, {R6-R9, PC}

     MOV     R7, R0                ; Stash device IRQ number into R7

     ; At this point, we know we have a HAL and we know we have a
     ; timer that we can use. So it's time to initialise things.

     ; Are we being re-initialised?
     LDR     R2, [R12]
     TEQ     R2, #0                ; If PrivateWord is non-zero,
     LDRNE   R12, [R12]            ; we already have workspace.
     BNE     skip_alloc

     ; If not, claim some workspace
     MOV     R0, #RMAClaim
     MOV     R3, #32               ; Claim 32 bytes
     SWI     XOS_Module
     LDMVSFD R13!, {R6-R9, PC}     ; Can drop out, unable to claim
     STR     R2, [R12]             ; Remember our workspace
     MOV     R12, R2

skip_alloc
     MOV     R0, #0
     STR     R0, [R12, #Counter]   ; Zero the counter
     STR     R7, [R12, #TimerIRQ]  ; Remember the device IRQ

     ; Read the granularity of the timer
     MOV     R0, #1                ; Timer1
     MOV     R8, #CallHAL
     MOV     R9, #TimerGranularity
     SWI     XOS_Hardware
     BVS     exit_at_rma_release   ; Tidy exit
     STR     R0, [R12, #Granularity]

     ; Claim vector for Timer1
     MOV     R0, R7                ; Timer device IRQ number
     ADR     R1, timerhandler
     MOV     R2, R12               ; is workspace pointer, *NOT* privateword
     SWI     XOS_ClaimDeviceVector
     BVS     exit_at_rma_release   ; Tidy exit

     ; Set timer period
     ; Set period before enabling IRQs in case it was set to a low value.
     MOV     R0, #1                ; Timer1
     LDR     R1, [R12, #Granularity] ; Load Granny for a one-sec tick
     MOV     R8, #CallHAL
     MOV     R9, #TimerSetPeriod
     SWI     XOS_Hardware
     BVS     exit_at_vector_release

     ; Enable IRQs for device
     MOV     R0, R7                ; Timer device IRQ number
     MOV     R8, #CallHAL
     MOV     R9, #IRQEnable
     SWI     XOS_Hardware
     BVS     exit_at_vector_release
     STR     R0, [R12, #IRQwasAlreadyOn] ; remember if there's another

     ; Initialisation finished
     LDMFD   R13!, {R6-R9, PC}



; =======================================
finalise
     ; Module finalise - can trash R0-R6 and R12.
     ; Entry stacks R6-R9,R14. Exit pulls.
     ;
     ; We can be called from various points in init
     ; to handle controlled exit.
     ;
     ; Because exit MUST complete, we only call X SWIs
     ; and all errors are ignored.

     ; Normal exit is thus...
     STMFD   R13!, {R6-R9, R14}
     LDR     R12, [R12]            ; Get pointer to workspace

     ; Disable generation of IRQs for device
     ; This is NOT called from init as this is last thing to be done.
     LDR     R0, [R12, #IRQwasAlreadyOn]
     CMP     R0, #0
     BNE     exit_at_vector_release; another user, so leave IRQs enabled
     LDR     R7, [R12, #TimerIRQ]  ; Retrieve Timer1 IRQ
     MOV     R0, R7                ; R7 = Timer IRQ
     MOV     R8, #CallHAL
     MOV     R9, #IRQDisable
     SWI     XOS_Hardware

exit_at_vector_release
     ; Release device vector claim
     MRS     R5, CPSR              ; Preserve flags in R5
     MOV     R6, R0                ; Preserve R0 (error block) in R6
     MOV     R0, R7                ; R7 = Timer IRQ
     ADR     R1, timerhandler
     MOV     R2, R12
     SWI     XOS_ReleaseDeviceVector
     MOV     R0, R6                ; Restore R0
     MSR     CPSR_f, R5            ; Restore flags

exit_at_rma_release
     ; Release workspace allocation
     MRS     R5, CPSR              ; Preserve flags in R5
     MOV     R6, R0                ; Preserve R0 (error block) in R6
     MOV     R0, #RMAFree
     MOV     R2, R12
     SWI     XOS_Module
     MOV     R0, R6                ; Restore R0
     MSR     CPSR_f, R5            ; Restore flags

     ; That's it
     LDMFD   R13!, {R6-R9, PC}    ; We're done. Bye bye!



; =======================================
commandtable
     ; *TCV    [TCV = Timer Counter Value (quicker to type!); UNREGISTERED!]
     =       "TCV", 0              ; no align, is four bytes
     DCD     (tcvcode - entry)
     DCD     0                     ; no parameters
     DCD     0
     DCD     (tcvhelp - entry)

     DCD     0                     ; end of list


tcvhelp
     =       "Reports value of Timer1 counter.", 0
     ALIGN


tcvcode
     ; *Command handler, registers R0-R6 and R12 are trashable.
     STR     R14, [R13, #-4]!      ; stack return address
     LDR     R12, [R12]            ; get workspace pointer
     LDR     R0, [R12, #Counter]   ; get current counter value
     ADD     R1, R12, #Workspace
     MOV     R2, #16               ; max is "4294967295" (10 characters) 
     SWI     XOS_ConvertCardinal4  ; turn it into a cardinal string
     SWI     XOS_Write0            ; print it out
     SWI     XOS_NewLine           ; (tidily!)
     LDR     PC, [R13], #4         ; done



; =======================================
timerhandler
     ; Timer IRQ handler. WE ARE IN IRQ MODE.
     ;   * Must leave machine in same state as entry (except R12)
     ;   * Must ONLY call X SWIs (nobody to pass error on to)
     ;   * Cannot call re-entrant SWIs
     STMFD   R13!, {R0-R11, R14}   ; stack *everything*

     ; We don't need to
     ;  LDR R12, [R12]
     ; as the handler was passed our workspace, so R12 is already correct.

     ; Drop into SVC mode
     MRS     R10, CPSR             ; Save original CPSR in R10
     ORR     R0, R10, #3           ; IRQ32 = 1 0 0 1 0 and SVC32 = 1 0 0 1 1
     MSR     CPSR_c, R0
     STR     R14, [R13, #-4]!      ; stack current R14_svc so we can call SWIs here

     ; Clear the timer IRQ
     MOV     R0, #1                ; Timer1
     MOV     R8, #CallHAL
     MOV     R9, #TimerIRQClear
     SWI     XOS_Hardware

     ; Clear the IRQ
     LDR     R0, [R12, #TimerIRQ]
     MOV     R8, #CallHAL
     MOV     R9, #IRQClear
     SWI     XOS_Hardware

     ; Counter++
     LDR     R0, [R12, #Counter]
     ADD     R0, R0, #1
     STR     R0, [R12, #Counter]

     ; Restore back to IRQ mode
     LDR     R14, [R13], #4        ; restore previous R14_svc
     MSR     CPSR_c, R10           ; restore previous CPRS

     ; Done, restore everything else and leave.
     LDMFD   R13!, {R0-R11, PC}



; =======================================
error_nohal
     ; Basically either OS_Hardware failed or it doesn't exist.
     DCD     1                     ; Not an allocated error block!
     =       "Incompatible HAL or no HAL present.", 0
     ALIGN

error_notimer
     ; We need at least two timers (can't mess with RISC OS's one).
     DCD     2
     =       "Sorry, at least two timers must be available.", 0
     ALIGN



; =======================================
     ; That's all folks. Go home.
     END

; ( but it has been mostly rewritten! ;-) )
GET ^.h.SWINames

Bit location specific.

How about this on the top end?

; ( but it has been mostly rewritten! ;-) )
     GET    Hdr:ListOpts
     GET    Hdr:SWIs

Works happily with the DDE.

Works happily with the DDE

Oh rats, SWIs.h doesn’t have the OS_Hardware etc defs

If the handler is in IRQ mode, why do you need to change to SVC mode?

If the handler is in IRQ mode, why do you need to change to SVC mode?

Because we are calling SWIs in the IRQ handler.

The reason we switch to SVC mode is to permit R14_svc to be preserved. If this is not done, the first SWI called would overwrite the version of R14 specific to SVC mode with the correct address for our return. Given that IRQs take precedence, it is quite possible that the system may be executing a SWI when the IRQ happens. As such, trashing R14_svc would be a really bad thing…

Rick,
I’ve just compared it with my own code and tried it. I’ve also added another function to restart the timer. There are some parts that I think they aren’t necessary. Thank you very much.
I’m going to try to replace the “OS_Hardware” parts with the hardware addresses mentioned in the ‘bcm2835’.
In this case we are using System Timer, do you think the Timer (P.196 of the BCM) could be used in this example as well?

Small quibble Rick, the comments say “at least 2 timers”

CMP R0, #2 ; Must have at least two timers
BEQ init_continue ; Branch if so, else…

But the code is checking for Exactly two timers…..

But the code is checking for Exactly two timers…..

Thanks. Fixed.

I’m going to try to replace the “OS_Hardware” parts with the hardware addresses mentioned in the ‘bcm2835’.

<facepalm>

Is there any specific reason why you really don’t want to use the proper API and would prefer to do things behind RISC OS’s back?

Won’t work anyway. Open a TaskWindow, then:

*Memory 20003000 +20

Address  :     3 2 1 0    7 6 5 4    B A 9 8    F E D C :    ASCII Data
20003000 :    00000000   00000000   00000000   00000000 : ................
20003010 :    00000000   00000000   00000000   00000000 : ................

Where’s… anything? Shouldn’t there be data here? Issue the *Memory command a few times. Nothing changes.

Hint! The addresses you are looking at in the documentation are the physical addresses. The address you see when you prod &20003000 within RISC OS is the logical address. I queried these addresses about two weeks ago. More than once. Please Google and take a quick refresher on what an MMU is and what it is for. Start with this.

If you really want to poke around with the hardware timer, you can access it by mapping in some physical memory (it will not be at the address &20003000):

*BASIC
>SYS "OS_Memory", 13, &20003000, 32 TO ,,,taddr%
>PRINT ~taddr%
  F9003000
>*Memory F9003000 +20

Address  :     3 2 1 0    7 6 5 4    B A 9 8    F E D C :    ASCII Data
F9003000 :    00000000   072FAF31   00000000   072FB584 : ....A./.....xu/.
F9003010 :    072FCCDC   072FD564   0737F7A7   74696D65 : UI/.do/.s.7.emit
>

Issuing *Memory multiple times will show the values changing, counting up. Rapidly. This is probably what you’re looking for.

That said, I STRONGLY RECOMMEND YOU STICK TO THE PROPER API.