OSHeap_Resize Should Have R3 as Output.

Tony van der Hoff tony at mk-net.demon.co.uk
Wed Nov 7 12:04:55 GMT 2001


On 6 Nov 2001, in message <3BE7D890.18136.5BFCA0 at localhost>,
"Jonathan Coxhead" <jonathan at doves.demon.co.uk> wrote:

>    On 6 Nov 2001, at 13:10, Tony van der Hoff wrote:
> 
> > In the overwhelming majority of cases an error return from a SWI
> > indicates that all bets are off. It wouldn't have been unreasonable for
> > the OS to return the shrunk amount in R3 in any case, without throwing an
> > error, and expect the client to make the comparison, but that's not what
> > was done.  We had to patch round this for OS_ReadVarVal, and I guess we
> > could do something similar here, if there was demand for it. It would be
> > possible to define new veneers, say OSHeap_ResizeReturnAmount, and
> > OS_ChangeDynamicAreaReturnAmount, which could interpret any error return,
> > and if appropriate, then return R3 with V clear, and R0 preserved, as if
> > no error occurred.
> > 
> > Is this worth doing?
> 
>    Worth doing, but very hard! Anything involving changes to DefMod's code 
> generation should only be undertaken after reading & understanding
> thoroughly  the "manual.htm" file (especially the section "APCS to SWI"), a
> period of  fasting in the desert, attaining oneness with the code, etc. Any
> change, no  matter how innocuous-seeming, breaks it. (In my experience ...)
> 
I certainly wouldn't even contemplate extending DefMod to do this; my
experience in rewriting the StrongHelp back-end required a few incantations
:-) In any case, it wouldn't be worthwhile for these few 'exceptions' to the
RISC OS API.

>    For OS_ReadVarVal we just wrote a veneer by hand, called
> riscos_var_len(),  and put it in the support directory. I think a similar
> way forward would be  best here: functions riscos_resize_heap(),
> riscos_change_dynamic_area() in  Support, with comments in the real veneer
> telling you about the "gotcha"  involved and pointing you at the new
> function.
> 
Ah, no, that's what you did a long time ago; but since then (I'm sure it was
your suggestion) I wrote a new veneer (OSReadVarValSize), in assembler, which
gets patched in to the library, replacing the DefMod-generated veneer. It's
in core.oslib.asm, and has been in use since ooh, 5.51, or so, although the
'maintainer wars' rather obscured its introduction ;-).

It would be quite straightforward to do this for the other two SWIs.

-- 
Tony van der Hoff         | MailTo:tony at mk-net.demon.co.uk
                          | MailTo:avanderhoff at iee.org
Buckinghamshire, England  | http:www.mk-net.demon.co.uk



More information about the oslib-user mailing list