oslib-team

[Jonathan Coxhead]

   On 30 Oct 2001, at 10:06, ralph at inputplus.demon.co.uk wrote:

> > There are some issues with doing this.  OSLib assumes AIUI that RISC OS
> > is the compilation environment where as riscose may be compiled where
> > an a char isn't unsigned by default, etc.

   Yes, OSLib makes several assumptions that in portable code would not be 
justifiable. Mainly, they are to do with structure layout: obviously, the SWI 
definition is in terms of byte offsets, and the OSLib structure are designed so 
that every field falls at the right offset. It "looks" very portable and nice, 
but if the assumptions go wrong (e, g, 2 shorts are not packed together, 
substructs not aligned at 4 bytes, array members aligned the same as non-array 
members etc), everything could go wrong. But, as the ARM is a particularly 
simple architecture, I wouldn't expect much to go wrong there.

   Also, char is assumed to be unsigned, so DefMod doesn't generate any sign-
extension code when an output value is type 'Char'.

> > It would also be nice to generate the `dispatch' code automatically
> > from the OSLib definitions, along with debug statements that can trace
> > every SWI's input and outputs.  Discussion with Matthew has only just
> > started on this and he's keen too.  The main issue is whether to take
> > the *.h files and scan them to generate our specific requirements, or
> > to use the yacc grammer to add another `backend'.  Given I'm at home
> > with yacc I prefer the latter.

   That would be much better: you have the YACC grammar already, and it 
generates a "neutral form"---a more-or-less direct translation of the syntactic 
structure into C structures and unions---that you can use to drive the rest of 
the process with little or no change.

   Hopefully :-)

        /|
 o o o (_|/
        /|
       (_/