os_claim

[Jonathan Coxhead]

 | The only type of function you need to worry about (for cmhg's benefit) is one
 | with the prototype:
 | 
 | void veneer_name(void)

   Then, to make the intent of calls like os_claim() clearer, we could just 
add ("by hand") to "types.h"

      typedef void arm_code (void);

& in DefMod, whenever a SWI has an argument of type ".Asm"

      R1 -> .Asm: routine

emit an argument of type

      arm_code *routine

 | All of the standard entry points have handwritten veneers anyway and you
 | shouldn't be calling things like module initialisation, service call handlers
 | etc. directly anyway (why would you want to?)

   Well, you'd want to if you were writing an operating system in C, I 
suppose. I understand it can be done. :-)

 | > [...] With those extra pieces, I think we'd have type-safe integration between 
 | > the various ways of hooking C code into RISC O S.
 | 
 | What's the point?

   Very little, it seems.

 | cmhg already declares the function for you in the header
 | file it generates, and generates all the necessary gubbins you need to set up
 | before entering the C code.  All you need is that the prototypes declared for
 | (x)os_claim et al accept a parameter of type "void (*)(void)".

   I agree. I think it would be better if that type had a standard name 
("arm_code *")---it would make the function prototype nicer to read, and 
also simplify the change needed in DefMod.

 | I do not believe that you should be interpreting CMHG's definition file. 
 | CMHG exports all the information you need from that file (with the single
 | exception of an assembler version of the SWI declarations suitable for
 | fitting into our RISC OS build system, which would be handy but can be lived
 | without)

   Fair enough!

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