Floating point instructions and modules
Christopher Bazley
everyone who responded to my ObjAsm/ASM query.
According to the chapter of the Acorn Assembler manual on writing
relocatable modules, floating point instructions should not be used in
SVC mode. Basically this means that you can't use FP instructions in
module code, such as SWI handlers.
Can this really be true? - I have never heard anything about such a
restriction elsewhere. In fact, I'm sure that there exists an AMPlayer
variant that is optimised for machines with an FPA.
Surely Acorn would not have defined the Draw_xxxFP variants of the
Draw module SWIs, unless the SWI code had access to the FP
emulator/co-processor?
On a related topic (sorry, I know I've asked this before), I want to
pass floating point arguments to SWIs in an efficient manner. There
doesn't appear to be any officially-sanctioned way of doing this - and
since Acorn never implemented the FP variants of the Draw SWIs, we'll
never know how they would have done it.
Although the PRMs do not explicitly say that FP registers should not
be used to pass parameters to a SWI, they do not forbid programmers
from using them in this manner. Surely RISC OS does not corrupt FP
registers before entry to a SWI handler? And if, as I suspect, it does
not corrupt them - is there any guarantee that this will remain the
case in future versions of RISC OS?
Any advice much appreciated...
Cheers,
Chris Bazley
Robin Watts
wrote:
> According to the chapter of the Acorn Assembler manual on writing
> relocatable modules, floating point instructions should not be used
> in SVC mode. Basically this means that you can't use FP
> instructions in module code, such as SWI handlers.
Calling FP instructions from SVC mode is a dodgy business. There are
all sorts of issues to do with the way that the FP emulation is done.
There are ways around the problem, but none of them are very nice,
and all have some sort of side effect.
> Can this really be true? - I have never heard anything about such a
> restriction elsewhere. In fact, I'm sure that there exists an
> AMPlayer variant that is optimised for machines with an FPA.
There is ideed such a variant. As you say, it is targetted for
machines with an FPA. Because these machines do the FP ops that
AMPlayer uses entirely in hardware this means that the FPE is not
called. Hence the restrictions are slightly different, and (with only
a small amount of jiggery pokery) we can get away with it.
> Surely Acorn would not have defined the Draw_xxxFP variants of the
> Draw module SWIs, unless the SWI code had access to the FP
> emulator/co-processor?
Pass.
> On a related topic (sorry, I know I've asked this before), I want
> to pass floating point arguments to SWIs in an efficient manner.
> There doesn't appear to be any officially-sanctioned way of doing
> this - and since Acorn never implemented the FP variants of the
> Draw SWIs, we'll never know how they would have done it.
Probably you'd pass pointers to the SWIs.
> Although the PRMs do not explicitly say that FP registers should not
> be used to pass parameters to a SWI, they do not forbid programmers
> from using them in this manner. Surely RISC OS does not corrupt FP
> registers before entry to a SWI handler? And if, as I suspect, it does
> not corrupt them - is there any guarantee that this will remain the
> case in future versions of RISC OS?
Don't even think about that. The problems (as with all such things)
come with reentrancy).
Robin
--
Robin Watts, Email: <mailto:Robin...@wss.co.uk>
Warm Silence Software, WWW: <http://www.wss.co.uk/>
P.O.Box 28, Woodstock, Tel: 01608 737172 (or Mobile: 07885 487642)
Oxfordshire, OX20 1XX Fax: 01608 737172
Mech
chris...@bigfoot.com (Christopher Bazley) wrote:
> Sorry to be back again so soon with another question - and thanks
> to everyone who responded to my ObjAsm/ASM query.
> According to the chapter of the Acorn Assembler manual on writing
> relocatable modules, floating point instructions should not be used
> in SVC mode. Basically this means that you can't use FP
> instructions in module code, such as SWI handlers.
> Can this really be true? - I have never heard anything about such a
> restriction elsewhere.
It's because the FPEmulator corrupts R14_SVC. Save it across FP
operations and it should be fine apart from that (IIRC).
Cheers,
Dan.
--
__ _______ ______ __
/ |/ / __/ ___/ /_/ / # Dan Maloney.
/ /|_/ / _// /__/ __ / # Disclaimer: Not my fault.
/_/ /_/___/\___/_/ /_/ # mailto:me...@toth.org.uk
druck
> Sorry to be back again so soon with another question - and thanks to
> everyone who responded to my ObjAsm/ASM query.
>
> According to the chapter of the Acorn Assembler manual on writing
> relocatable modules, floating point instructions should not be used in
> SVC mode. Basically this means that you can't use FP instructions in
> module code, such as SWI handlers.
As other people have mentioned, it is possible but modules have to take
special actions to guard against the side effect of the way the FP emulator
works. Changes were made in RISC OS 4 to support FP in SVC mode which will
make it easier to use in future.
> Can this really be true? - I have never heard anything about such a
> restriction elsewhere. In fact, I'm sure that there exists an AMPlayer
> variant that is optimised for machines with an FPA.
Because machines with FPA use the co-processor to execute the instrucion
rather than them being emulated via undefined instruction trap, the side
effects do not apply - note however not all FP instructions are executed
by the co-pro complex trig functions are still emulated in software but
still quicker as the simple FP instructions can be used in the emulator.
> Surely Acorn would not have defined the Draw_xxxFP variants of the
> Draw module SWIs, unless the SWI code had access to the FP
> emulator/co-processor?
It would have been up to Acorn to overcome any problems in thier
implementation.
> On a related topic (sorry, I know I've asked this before), I want to
> pass floating point arguments to SWIs in an efficient manner. There
> doesn't appear to be any officially-sanctioned way of doing this - and
> since Acorn never implemented the FP variants of the Draw SWIs, we'll
> never know how they would have done it.
You should pass FP arguments via the FP registers. Note however on an
emulated FP system this will be slower than passing pointers to the
fp arguments in memory, or in the case of single precision arguments, in
registers. For more information see documentation on the ARM proceedure
calls standard in the PRM's/DDE documents.
> Although the PRMs do not explicitly say that FP registers should not
> be used to pass parameters to a SWI, they do not forbid programmers
> from using them in this manner. Surely RISC OS does not corrupt FP
> registers before entry to a SWI handler? And if, as I suspect, it does
> not corrupt them - is there any guarantee that this will remain the
> case in future versions of RISC OS?
I would say it is pretty certain that the SWI dispatacher will not corrupt
FP arguments, as this would preclude their use for passing parameters and
devalue the work done to make FP safe in SVC mode.
---druck
--
The ARM Club * http://www.armclub.org.uk/
Mech
Mech <me...@toth.org.uk> wrote:
> In message <464f803d.02011...@posting.google.com>,
> chris...@bigfoot.com (Christopher Bazley) wrote:
> > Sorry to be back again so soon with another question - and thanks
> > to everyone who responded to my ObjAsm/ASM query.
> > According to the chapter of the Acorn Assembler manual on writing
> > relocatable modules, floating point instructions should not be
> > used in SVC mode. Basically this means that you can't use FP
> > instructions in module code, such as SWI handlers.
> > Can this really be true? - I have never heard anything about such
> > a restriction elsewhere.
> It's because the FPEmulator corrupts R14_SVC. Save it across FP
> operations and it should be fine apart from that (IIRC).
Plus, (I forgot) I think that any FP instructions referencing R13
or R14 use the user mode bank to obtain those registers. This means
that you'd have to load the stack pointer into another register to
save/restore the FP regs on the stack (don't then forget to decrement
R13, hehe).
And the FPEmulator probably uses the SVC stack, so leave R13_SVC
pointing to somewhere sensible...
...can't think of anything else...
Probably this makes it all not-very-do-able from C at any rate.
As for the passing FP registers to an SWI I don't know how you
do that (ew). I'll go along with whatever Robin Watts says. :-)
Stewart Brodie
chris...@bigfoot.com (Christopher Bazley) wrote:
> According to the chapter of the Acorn Assembler manual on writing
> relocatable modules, floating point instructions should not be used in
> SVC mode. Basically this means that you can't use FP instructions in
> module code, such as SWI handlers.
>
> Can this really be true? - I have never heard anything about such a
> restriction elsewhere. In fact, I'm sure that there exists an AMPlayer
> variant that is optimised for machines with an FPA.
Yes it is true. The problem is that when the undefined instruction abort
occurs, R14_svc is overwritten. In RISC OS 3.5 and later of course, R14_svc
is not immediately corrupted as the return address is written to R14_und
instead. However, depending on the version of RISC OS, the code will fall
back to SVC mode and end up corrupting R14_svc anyway. I can't remember for
which versions this happens.
> Surely Acorn would not have defined the Draw_xxxFP variants of the Draw
> module SWIs, unless the SWI code had access to the FP
> emulator/co-processor?
All those SWIs return a "Not Implemented" error (as you note below)
You can do what the Font Manager does though, and emulate floating point
using multiple integer registers. It isn't necessarily all that much less
efficient if you do it right.
> On a related topic (sorry, I know I've asked this before), I want to pass
> floating point arguments to SWIs in an efficient manner. There doesn't
> appear to be any officially-sanctioned way of doing this - and since Acorn
> never implemented the FP variants of the Draw SWIs, we'll never know how
> they would have done it.
Hard to say. The SWIs themselves don't have to accept any floating point
values, do they? I thought it was mostly pointers to path definitions and
the like, in which case there's no problem.
If I were to define a SWI interface along those lines, I think I'd try and
stick to a set of constraints that closely mimic the fp-register passing
variants of APCS to assist integration into applications - ie. use only F0-F3
for register passing, F0 to return results, always preserve F4-F7. Consider
the FPSR too - I can't remember what you're supposed to do with it on a call
(preserve it?)
> Although the PRMs do not explicitly say that FP registers should not be
> used to pass parameters to a SWI, they do not forbid programmers from using
> them in this manner. Surely RISC OS does not corrupt FP registers before
> entry to a SWI handler? And if, as I suspect, it does not corrupt them - is
> there any guarantee that this will remain the case in future versions of
> RISC OS?
Unofficially, I would have thought that there is no chance of the RISC OS SWI
dispatcher touching those registers. I think it would be up to you to
specify in your SWI documentation any usage of FP registers, with the
implicit preservation of unmentioned registers (just like the integer
registers). Then there is the issue of FPSR preservation too. You wouldn't
necessarily want SWIs messing around with all those status flags.
--
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/
Martin Wuerthner
Stewart Brodie <stewart...@pace.co.uk> wrote:
> In message <464f803d.02011...@posting.google.com>
> chris...@bigfoot.com (Christopher Bazley) wrote:
>
> > According to the chapter of the Acorn Assembler manual on writing
> > relocatable modules, floating point instructions should not be used in
> > SVC mode. Basically this means that you can't use FP instructions in
> > module code, such as SWI handlers.
> >
> > Can this really be true? - I have never heard anything about such a
> > restriction elsewhere. In fact, I'm sure that there exists an AMPlayer
> > variant that is optimised for machines with an FPA.
>
> Yes it is true. The problem is that when the undefined instruction
> abort occurs, R14_svc is overwritten. In RISC OS 3.5 and later of
> course, R14_svc is not immediately corrupted as the return address is
> written to R14_und instead. However, depending on the version of RISC
> OS, the code will fall back to SVC mode and end up corrupting R14_svc
> anyway. I can't remember for which versions this happens.
Does this really depend on the version of RISC OS and not rather on the
version of FPEmulator? In other words, could it be the case that one of
the more recent FPEmulator versions is safe to be used in SVC mode? In
that case, the caller could simply check whether it is safe to use FP
instructions or not. Or do you think that the problem is already in the
RISC OS veneer code that is called by the undefined vector?
By the way, many thanks for your continued postings here, Stewart. It is
always good to see some background information beyond what is written in
the official documentation!
Martin
--
---------------------------------------------------------------------
Martin Wuerthner MW Software mar...@mw-software.com
---------------------------------------------------------------------
Martin Wuerthner
Robin Watts <Robin...@wss.co.uk> wrote:
I do not think that there is a problem. It is a safe bet to assume that
the SWI dispatcher does not corrupt the FP regs, so they will arrive OK on
entry to the SWI. Interrupt code has to preserve the FP registers. For the
above reasoning, it does not make any difference whether the FP registers
are emulated or in hardware. In fact, you can even have reentrant SWIs
receiving FP register arguments.
However, considering what Stewart Brodie has written on the subject of
actually using FP instructions in SVC mode, it seems that there is not
much that the SWI could do with the FP arguments. :-)
Stewart Brodie
Martin Wuerthner <mar...@mw-software.com> wrote:
> In message <29595afd4...@sbrodie.cam.pace.co.uk>
> Stewart Brodie <stewart...@pace.co.uk> wrote:
>
> > In message <464f803d.02011...@posting.google.com>
> > chris...@bigfoot.com (Christopher Bazley) wrote:
> >
> > > According to the chapter of the Acorn Assembler manual on writing
> > > relocatable modules, floating point instructions should not be used in
> > > SVC mode. Basically this means that you can't use FP instructions in
> > > module code, such as SWI handlers.
> > >
> > > Can this really be true? - I have never heard anything about such a
> > > restriction elsewhere. In fact, I'm sure that there exists an AMPlayer
> > > variant that is optimised for machines with an FPA.
> >
> > Yes it is true. The problem is that when the undefined instruction
> > abort occurs, R14_svc is overwritten. In RISC OS 3.5 and later of
> > course, R14_svc is not immediately corrupted as the return address is
> > written to R14_und instead. However, depending on the version of RISC
> > OS, the code will fall back to SVC mode and end up corrupting R14_svc
> > anyway. I can't remember for which versions this happens.
>
> Does this really depend on the version of RISC OS and not rather on the
> version of FPEmulator? In other words, could it be the case that one of
> the more recent FPEmulator versions is safe to be used in SVC mode? In
> that case, the caller could simply check whether it is safe to use FP
> instructions or not. Or do you think that the problem is already in the
> RISC OS veneer code that is called by the undefined vector?
It's a combination of the OS and the FPEmulator module. A "32-bit"
FPEmulator can install a pre-veneer or whatever it's called and get in whilst
the processor is still in UND mode and thus take steps to preserve R14_svc.
Obviously it can only do that on machines with ARM processors that have
32-bit modes (Risc PC600 and later).
To be honest, I don't know exactly how it all works internally - I've not
fiddled with that module myself.
You will find that bad things happen if you run an AMPlayer which uses FP
instructions on a machine without FP hardware or a suitable emulator.