On Apr 10,  6:51pm, WILCOX MATTHEW EXC CP CH wrote:
> Subject: speedy FP
>
>  Just wondering if my idea can be applied to RiscBSD - I don't know about how
> the ARM FPE works, but this should considerably reduce the amount of time
spent
> in the kernel by FP intensive apps.
>
> For those who don't frequent c.s.a.programmer, my idea is essentially to
> have the handler for the FP instruction exception trap decode the arguments,
> put them in a table indexed by address then overwrite the FP instruction with
a
> BL to some handler routine which would then pick the results from the table
and
> emulate the instruction.  This should produce a considerable increase in
speed
> and reduction of time spent in SVC mode.

I considered this idea about a year ago but rejected it because it has one or
two horrible side-effects. Quite apart from having to make sure that r14 is
safe to use which Richard Earnshaw has already mentioned, modifying the text
segment of a RiscBSD a.out binary has some non-trivial side-effects.

The text segment is marked read-only by default so you have to mark it
read-write before fixing it up. This involves mucking around with page tables.
If the page is shared between multiple processes (ie if multiple processes are
running the same binary) then marking the page writeable will force it to be
uncached (ie you will force a data-cache flush - on a StrongARM this is painful
- several thousand times as long as the FP instruction decoding phase). If you
don't want to run your binary with the cache off then you need to mark the page
read-only again so that the cache can be switched back on. This means that the
next floating point instruction will cause a data-cache flush too. Of course
the original floating point instruction will still be in the instruction cache
unless you flush that too. I don't even want to think about what would happen
if you started paging.

Cheers

Rob