Not sure how useful it is - I haven't checked what's on there.

Wimp2 seems to be at http://www.nedprod.com/programs/RISC-OS/Wimp2/ for those who are interested...

http://www.armclub.org.uk/free/

Dunno how to use it, I've just downloaded it for the first time and I can't open it on this here PC.

I've written some of the new version of fred, and may soon be in a state to test it (albeit cooperative multithreading only).

Random, yes, but I presume you've all looked at Wimp2.

That's preemptive multitasking, rather than multithreading though. Granted, they could be implemented in very similar ways, but preemptive multitasking also has to handle the WIMP interface (rather than just a start/stop/status interface) and it might be able to assume more stuff due to being in a task environment (though I'm not sure about that - multithreading would probably be restricted to USR mode too).

On second thoughts, I don't know enough about it. Perhaps it does do all you need and then some.

Wimp_CloseDown message & service are always sent when a task which has called wimp_initialise finishes, and if a task doesn't call it, the wimp does so on its behalf, so you can rely on that. In theory a task can continue after calling wimp_closedown, just as it did before initialising, and presumably can call wimp_initialise again as a different task. Bear it in mind, perhaps?

HTH

The current method uses OS_ChangeEnvironment to get the 'currently active object' pointer. However this returns &8000 for both single tasking and multitasking programs, so is useless for telling them apart.

I think I may be able to do it though:

* Use a vector to track when programs start. At this point fred will enter a 'single tasking' mode
* If a fred_init call is made, then stay in single tasking mode. Register an exit handler with OS_ChangeEnvironment so that fred knows when the task quits, at which point multitasking mode will be reentered.
* However if a WIMP_Initialise message is received, enter multitasking mode and use a WIMP call to identify the currently running program whenever fred functions are called (If there is a call to do this, that is...).
* Then, either listen out for WIMP_Shutdown messages or register an Exit handler as above to identify when the task quits - I'm not sure, but tasks may continue to run single-taskingly after calling WIMP_Shutdown, so fred must be able to cope with this.

Hopefully the above is possible, and will work...

I still haven't looked at TimerMod though

I don't think you should do any timers which can be stoped and started; apps can just do the subtrqacting themselves. If you let them be stopped apps start interfering with each other.

Yes, that's what I was worrying about.

I've *almost* got the new version working. Everything seems OK, but there's a bug in the preemption code that locks up the computer. I think it's in some form of exit/shutdown code, but it could be anything...

Random, yes, but I presume you've all looked at Wimp2.

Um, no I'll track down a copy...

Lee: I had a look at rozilla.com, but it seems to be nothing to do with programming/RISC OS/Martin Piper!

I've got fred working again now (turned out one function wasn't allocating enough memory for the thread info objects ), and am now working on the preemptive code...

Hopefully I'll have a verdict on whether it works by tomorrow...

I've thought up a sneaky way of getting the current app. First, use OS_ChangeEnvironment to check that the current app is running at &8000. Then, use OS_FindMemMapEntries to find which page is mapped to &8000 - since RISC OS swaps pages rather than big lumps of RAM, this should be unique for each app running

All I need to do now is add some code to track apps which die unexpectantly, by doing two things:

1. Registering a function with atexit(), so normal exits work OK
2. Registering a function with most/all the signal handlers, so fatal errors and the like can be tracked. Unfortunately there are a ton of extra signals in UnixLib than the shared C library, so I'll have to think up some way of detecting the library in use or something. Plus signal handler functions can't be chained together, so if a Fred user uses their own handler then they'll have to make sure it calls fred_finish() if it terminates the program.

I'll also have a look at how Wimp2's 1ms timer worked, so I can implement one of those. I may release it as a seperate module since a 1ms timer could be useful in quite a few things.

Damn right it would be.

Once I've got the preemptive code working, I'll have a look at some threading systems and see what features they support, as well as have a nice release version for you people

POSIX threads (or pthreads) would be a class place to start as a port of the POSIX API would probably be a huge help to anyone porting from linux.

Multithreading now works, but a bit dodgily - if a program exits without functions registered by atexit() being called, (i.e. escape being pressed or some form of crash/error), then you'll get an abort on instruction fetch where OS_CallAfter is trying to run code which no longer exists

I'll rewrite the entire thing as a module and then release a copy rather than release a semi-working copy right away.

I've also found (By looking at Martin Piper's pthread port) why it isn't working with the shared c library. As usual it's a case of me not reading the PRMs properly (Or Acorn not making it obvious enough ). There are 7 reserved words at the top of each stack chunk that I was failing to copy over when creating new ones - and now I think of it I should have realised that earlier, since module code references data held there

I'll also have a look at how Wimp2's 1ms timer worked, so I can implement one of those. I may release it as a seperate module since a 1ms timer could be useful in quite a few things.

Once I've got the preemptive code working, I'll have a look at some threading systems and see what features they support, as well as have a nice release version for you people

Unfortunately the same isn't true with unixlib - atexit() functions do only get called when the program exits normally. At the moment I'm busy fiddling round getting the signal handlers working properly so they can trap the other occurences.

I've managed to implement some clib/unixlib detection code which works fine in GCC, even if it's a bit messy. Once the signal handlers are working properly, this code will decide whether to run the clib fred_init function or the unixlib one (Or a third one which lets you specify whether a function is registered with atexit(), and which signal handlers are registered). At the moment the signal numbers used are hard coded, but that shouldn't be a problem.

I still need to get a registered SWI base sorted out, and have a look at TimerMod though

Also, to increase the accuracy of the thread switching, each app has its own 'time till next switch' value. The value for the current app gets decreased every 'time unit' (at the moment every centisecond), so that it knows which app needs thread switching when. This is instead of using OS_CallAfter to set up a switch to occur at some point in the future, without even knowing whether that app will have been active for the full duration of that time.

I've had a look at TimerMod, and I think it might be easier if I just wrote my own version instead of trying to get that one updated.

I don't really know until I try it though, and the amount of work needed doesn't sound too tasty at the moment

It does look that way - maybe you should do it 'over the summer' ...

Still no progress on the CLib front though

If the thread switching was based around timed interrupts (i.e. OS_CallAfter), then the routine to do the switching wouldn't have any idea what the registers are the program is using - because RISC OS would have them somewhere at the start of its stack

Which means one of two things - pulling apart the stack (Bad idea, unless there's something in the PRMs I haven't noticed), or writing my own interrupt handler to replace the one in the hardware vector table at the base of RAM. This would look at the interrupt and if its a fred-specific one call the fred code, otherwise pass it on to the RISC OS code. I'll have a look at the PRMs to see how tricky this would be.

Got bored half way through vol 1 though

The bookmark is still there though, so who knows what I might get up to this summer

Um, expect some more fred stuff tomorrow. has requested some more detailed info on how it works for newbie-ish assembler/C type people, so that'll be occupying me most of tonight. I'll check the PRMs for the hardware vector stuff though.