OS_CallEvery

What is meant by OS_CallEvery workspace pointer? I have a timer interrupt handler like this:

.timer
  STMDB SP!, {R0-R3}  ; push to (supervisor) stack
  ...
  LDMIA SP!, {R0-R3}  ; pop from (supervisor) stack
  MOV   PC, LR        ; return

This is called in supervisor mode, so its using supervisor stack, which is OS defined. And handler accesses global variables from within task memory, which is also OS defined. Therefore I register handler with dummy workspace pointer = task memory base, and this works fine:

  MOV   R0, #50         ; timer 0.5 sec
  ADR   R1, timer
  MOV   R2, #&8000
  SWI   "OS_CallEvery"  ; timer start
  ...
  ADR   R0, timer
  MOV   R1, #&8000
  SWI   "OS_RemoveTickerEvent"  ; timer stop

So what is workspace pointer used for? Dynamic memory allocation within handler? But I am not using local variables in handler.

And if workspace pointer is indeed required, what is the recommended method to reserve memory for it? Through OS_Memory 23?

It’s expecting the handler to be in a relocatable module, where R12 is the module’s workspace pointer.

OS_CallEvery doesn’t need a workspace pointer, the value in R2 when it’s setup is simply a value passed in R12 when your code is called.

> OS_CallEvery doesn’t need a workspace pointer

OS_CallEvery seems to use the workspace pointer for “something”

When I use one workspace pointer address to register the handler address with OS_CallEvery, and a different workspace pointer address to de-register the handler address with OS_RemoveTickerEvent, then after de-register there is Internal error: abort on data transfer

Could the workspace be used by OS_CallEvery to “remember” the previous TickerV for OS_RemoveTickerEvent to restore it?

When I use one workspace pointer address to register the handler address with OS_CallEvery, and a different workspace pointer address to de-register the handler address with OS_RemoveTickerEvent, then after de-register there is Internal error: abort on data transfer

The docs for OS_RemoveTickerEvent https://www.riscosopen.org/wiki/documentation/show/OS_RemoveTickerEvent say that it will remove events that match the code address and workspace pointer, so I guess if you don’t give it the same one it won’t de-register the code. If the code is then removed, you’ll probably get crashes.

Yes, it is possible to use the same handler with different workspace, or (in the car of modules), different handlers with the same workspace.

They must match up – what you specified on creation must match what you specify on removal…even if the workspace pointer is zero…

in the car of modules

Auto-incorrect strikes again

Testing both work link and ROOL forum access through a PAT pool gateway and a proxy plus AV filtering…

Yup. And with a small screen it got missed…