os_claim

[Stewart Brodie]

In message <200012112003.MAA18437 at purple.trimedia.sv.sc.philips.com>
          "Jonathan Coxhead" <jonathan at doves.demon.co.uk> wrote:

> In CMHG, there is a facility to declare an irq-handler. This generates a
> wrapper that makes a piece of assembler (by intent, an IRQ handler, though 
> it works for other things too)

Using irq-handler has been deprecated for years.  CMHG supports a new term
generic-veneers which better conveys the purpose of the veneer.  The old name
is still accepted but causes a warning.  I thought this was shipped as part
of Acorn C/C++.  If not, then developers should have a version that does
this.  Anybody with the 32-bit libraries will have a version of CMHG that
does support it though - although I re-iterate the warning that you should
not use that cmhg to generate *32-bit* module headers right now because the
code generated by cmhg 5.33 provokes a StrongARM bug :-/   26-bit module
headers ("cmhg -26bit") works fine.  Hopefully a fixed cmhg will be released
very early in the new year.

> [discussion of how defmod needs to create os_cmhg_veneer type]

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

void veneer_name(void)

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?)

>    In the CMHG file, we'd have something like
> 
>       service-handler: service/service-wrapper
> 
> which generates the wrapper |service_wrapper|, and OSLib functions that 
> deal with service calls would have parameters of that type 
> (|osservice_wrapper|).
> 
>    So finally, we'd need a tool that read the CMHG file, and produced a C 
> header file like this:
> 
>       #include "os.h"
>  
>       extern osservice_handler service;
>       extern osservice_wrapper service_wrapper;
> 
>    With those extra peices, I think we'd have type-safe integration between 
> the various ways of hooking C code into RISC O S.

What's the point?  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 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)

I managed to cut out the query of whether cmhg is still supported or not.  It
is - via RISCOS Ltd.

-- 
Stewart Brodie, Senior Software Engineer    (Views expressed are my own and
Pace Micro Technology PLC                   not those of my employer)
645 Newmarket Road
Cambridge, CB5 8PB, United Kingdom         WWW: http://www.pacemicro.com/