In message <E0C2B1A26DE8456E81DBACDDFD4BD7E2@Dell>
Terje Slettebø <[email protected]> wrote:
> I'd like to take a stab at reimplementing the WindowManager module using
> C/C++, in particular to make further development easier and while most of
> its SWIs behave "function-like", i.e. return (directly) to their caller, a
> few do not, in particular those having to do with creating new tasks and
> switching between them, such as Wimp_StartTask and Wimp_Poll.
Ambitious, but interesting and I like to hear how hear how it goes on.
As side remark: I'm very much in favour to start using C for RISC OS
module development. Much more efficient concerning development times,
ease to refactor your code base when needed, easier to locate & fix
bugs, etc. On the other hand, such C based modules are larger than
their ARM coded counterparts but personally I don't think that should
be as relevant today as it was when we were dealing with 1M Archimedes
machines. RISC OS developer time is much more precious than runtime
memory usage IMHO.
FYI, Martin and I used GCCSDK 4 for our PS3 development using CMunge and
OSLib and we didn't regret it a single moment having made that choice.
> With CMunge, you define a C/C++ function to be called when a SWI is called,
> and when you return from the function, it returns from the SWI, as well.
>
> However, in the case of Wimp_StartTask, the transfer of control is something
> like this:
>
> (Current task) -> Wimp_StartTask ("e.g. *SomeWimpTask) (This probably pages
> out the "Current task" from &8000, sets up &8000 with the amount of money
> specified in the "Next" slot, and issues the command, *SomeWimpTask) ->
> SomeWimpTask -> OS_Exit/Wimp_Poll -> Set up original task context and return
> from Wimp_StartTask.
>
> This doesn't look like a function call to me... :)
>
> Does anyone have any ideas of how one might implement such SWIs, without
> having to do them in ARM assembly, in order to store the return address, set
> up context for the new task, etc.?
CMunge's generated code does not really care about your function returning
or not. I.e. just realise that your C function is called using
SVC stack on which your local variables are being stored and feel free
to call any SWIs including OS_Exit (you can tag such function with
GCC's __attribute__ ((noreturn)) to tune the generate code).
Of course if you're going to switch from processor mode (e.g. to USR), you
have to be careful and know what's going on.
Just to make sure you know these points:
- you can use inline assembler (see source code of SOManager source code)
- if you don't want to code your SWI calls yourself, consider using OSLib
but unfortunately I've never got around releasing an ELF based OSLib which
can be used with GCCSDK 4. However, either you can build OSLib yourself
using the latest SF sources, either grab a copy at
http://joty.drobe.co.uk/oslib/
- if you have constant local/global variables, consider making them
'const'. This avoids constant data to be placed in RMA workspace (and
extra pointer calculation on access).
John.
--
John Tytgat, in his comfy chair at home BASS
[email protected] ARM powered, RISC OS driven
_______________________________________________
GCCSDK mailing list [email protected]
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
