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