Wimp_Poll called from a module for a user space task

I have been working on a module and found something strange happening.

An SWI call is made from BASIC to my module. The code in that SWI (in my module) calls Wimp_Poll or Wimp_PollIdle on behalf of the task.

Anything I do with registers after the Wimp_Poll call are ignored when returning to BASIC.

For example, I use SYS “MyModule_MySwi”,a,b,c,d TO a,b,c,d in BASIC. That SWI code calls Wimp_Poll using a,b,c,d and gets the reason code in R0 (a). I then use ADD R0,R0,#1 and return to the BASIC task which you would expect would make the reason code returned one higher than expected. It does not. It returns the reason code. I have checked and double-checked I am not saving R0 off anywhere, on a stack or anywhere. Anything I do after Wimp_Poll with registers are ignored for return values, yet the code runs. Shove an unidentified instruction instead of the ADD and it errors out.

Why would this be? Is it because I am calling Wimp_Poll from a module area (the R14 return address is checked)? Something to do with being in the wrong mode? Or is the context swapping getting confused somewhere because what I am doing is not standard?

If you are really using a,b,c,d as BASIC variables perhaps being floating point confuses things?
Try a%,b%,c%,d% and see if it changes.

It was an example – I wrote the code a while back and checking it I am not passing any variables at all. They are all being set within my module. R0 set to 1 to mask null events (MOV R0,#1), R1 set to some space reserved in the R12 module pointer that I took with OS_Module 6 (Claim Memory) on module initialise.

Changing R1 to a pointer in user space (sent by the BASIC task) is something just attempted. Interesting that it returns a bad pointer error. The WIMP must know I am calling from module code with a user space block that can be paged in an out.

I am not passing any variables at all.

So how are you reading the registers in BASIC after the SWI?

The WIMP must know

I suspect it just discovers when it tries to use it and it is paged out.

I noticed lots of issues when ADFFS was calling Wimp_Poll from the Module area – on behalf of an application. Calling Wimp_Poll via OS_CallASWI also causes problems. The workaround I used was to do what BASIC does and relocated the SWI into Application space before calling it.

I’m also not sure where the CAO will be pointing in this scenario. You might need to repoint it at &8000 via OS_ChangeEnvironment to avoid issues if it task-switches.

If you can rework your Module so that it returns and allows the Application to issue the Wimp_Poll, that will be the least problematic. If that isn’t an option, pass a block of Application memory to the Module so it can place SWI XWimp_Poll in Application space before its issued in User mode.

You’ll also need to be very careful about where Error handlers and Vectors are pointing, so you might want to add OS_DelinkApplication / OS_RelinkApplication around the Wimp_Poll call – just in case.

If you can rework your Module so that it returns and allows the Application to issue the Wimp_Poll, that will be the least problematic. If that isn’t an option

Would using a pollword here help?

I have been working on a module and found something strange happening.

An SWI call is made from BASIC to my module. The code in that SWI (in my module) calls Wimp_Poll or Wimp_PollIdle on behalf of the task.

You cannot do this. Wimp_Poll, Wimp_PollIdle and Wimp_StartTask must never be called from SVC mode. Or at least, if they are, you must be aware that you will never see the results from your call, and in fact the call will return immediately and the next return to USR mode will return with the results from Wimp_Poll.

It is not the location of the code calling the SWI which causes this problem, but the fact that you are in SVC mode. These calls cannot function from within SVC mode, due to the mechanism by which they work. Instead of calling the Wimp_Poll SWI yourself, provide an alternative SWI call that can be called before the user’s Wimp_Poll SWI to manipulate the registers, and a further one if you wish to post process the Wimp_Poll SWI’s registers. Consult the documentation on the Interface module for details of how this was done historically.

If you are trying to provide additional operations to the task, then consider using the FilterManager to post-process the returns from the Wimp_Poll calls. This is the mechanism by which the ColourPicker functions, and also partially how the Toolbox functions.

Thanks everyone. I have been doing the wrap around (a pre-SWI to call to my module, then a Wimp_Poll call, then a post-SWI call). This works fine but I would have preferred a simpler way.

I’ll just have to stick with that at the moment.

I have tried suggestions and things I’ve found on this forum including swapping to user mode, callee mode, DelinkApplication, AMBControl 5 (lazy paging) and pollwords with no success! So the wrap-around will have to stay.