Article on Unixlib

John Tytgat John.Tytgat at
Wed Jan 12 15:48:12 PST 2005

In message <67474b2b4d.ajw498 at>
          Alex Waugh <alex at> wrote:

> In message <66ab472b4d.Jo at>
>           John Tytgat <John.Tytgat at> wrote:
> > In message <3f4a3c2b4d.ajw498 at>
> >           Alex Waugh <alex at> wrote:
> > 
> > [...]
> > > Also, I'm not convinced that the code to set and retore handlers with
> > > OS_ChangeEnvironment is entirely correct in all circumstances, although
> > > I can't see anything specifically wrong with it. I hope to simplify
> > > this which may flush out any remaining bugs in this area.
> > 
> > I wasn't aware of any bugs in this area.  You have more info ?
> No, just a vague suspicion really. Occasionally, a program in a
> taskwindow has got into an infinite loop somehow, with escape having
> no effect, and if you close the taskwindow then there is a complete
> machine freeze. It is entirely possible however that this is unrelated
> to the environment handlers.

I don't think I've seen this behaviour before but I would indeed suspect
something wrong with the environment handlers because closing
the taskwindow means calling the Exit handler.  If that aborts or loops
(e.g. the DataAbort handler is deregistred but the Exit handler issues
a DataAbort, then the default DataAbort handler will be use which invokes
the Exit handler again...), the game is over (I assume the
pointer/interrupts still work, right ?).

If you have some code showing this behaviour, I wouldn't mind helping
finding the underlying problem.

> [...]
> > It is a bit difficult to state the following without having concrete
> > plans but my feeling was that we better are first in a position to build
> > RISC OS modules with gcc before attempting to move specific job data,
> > file handles, etc to SUL instead of all hand coding.  Otherwise, we
> > are force to write everything in assembler and maybe because of this,
> > we're only doing half-job.
> I don't think this is the case, because:
> I don't intent to move that much code into the SUL. If the process
> structure is well defined and extensible then most of the code to
> access it can remain in UnixLib.
> The two main bits of code I want to move into the SUL are the
> environment handlers and the fork/exec code, both of which are
> currently written in assembler, and probably will have to remain so.

I'm not convinced that just moving that part of the current assembler code
to SUL will result in a better code.  I'm just afraid it will even become
more difficult to follow how things work and put a burden on SUL to remain
and support this interface for the new UnixLib static compiled programs
for quite some period. The moment we have UnixLib as a dynamic library
this becomes less of an issue as making incompatible changes in the
dynamic library can go together with an update of SUL.

> If the SUL code is called as APCS routines, then it could be written in
> C and compiled as non-module code. It would only need to be module code
> if it was accessed directlty from the module, e.g. as SWI calls.

You're right, so that means no (or not a big) dependancy on the module GCC

> > [...]
> > > A SWI interface for implementing fork() wouldn't work because it would
> > > need to return from the SWI twice.
> > > Any code implementing a SWI will be running in SVC mode, which I want
> > > to avoid as much as possible.
> > 
> > There a lots of ways to address those items :
> > 
> > 1. Would a fork() doing a Wimp_StartTask help ?
> In what way? If fork() is implemented by calling a SWI, then that SWI
> would have to return to the child program, then when the child has
> exited somehow jump back into the SWI and return a second time to the
> parent.

Apologies for my reasoning being a little bit jumpy but if we have fork()
working so that the new child becomes a separate Wimp task, then we don't
need the moving data/parent code anymore and we don't need to deregister
the parent environment variables anymore.

If Wimp_StartTask returns a non-zero value, we have a child which is
another Wimp task happely running.  By monitoring Message_TaskCloseDown
or service call WimpCloseDown, we could know implement things like wait()/

An exec() of a vforked child could use a similar Wimp_StartTask

> > 2. SUL could make a set of user mode callable routines available instead
> >    of real SWI routines.
> Isn't this more or less what I'm proposing?


> > 3. SWI code can drop into USR (and back to SVC).
> It can, but why then bother with the overhead of a SWI call?

True.  And the need of GCC C support for a module I assume.

John Tytgat, in his comfy chair at home                                 BASS
John.Tytgat at                             ARM powered, RISC OS driven

More information about the gcc mailing list