Re: It boots!
>6. Write a small C program, init-boot, which does only three things:
Yes, that's a good idea.
>In the long term, I'd expect that using soft-float (2) would be better
>than using a floating point trap emulator, for reasons of efficiency,
>but having both would allow you to also support binaries which expect
>an FPU, too. (I can't imagine a trap being quicker than in-line code.
>OTOH, on the ARM, there might not be much difference.)
If you tell GCC that you're using an emulator it can arrange to schedule all
your floating point instructions in groups, which makes emulation faster (as
opposed to scheduling for hardware float when it's better to try for
more parallelism between the integer and float units). I think a soft-float
scheme will always be slightly faster - the trap overhead itself isn't too
bad, but doing the instruction decode is reasonably painful. That said,
someone, maybe Scott, mentioned that they'd done some measurements and found
that the trap overhead wasn't all that great after all.
>In fact, if GCC can open-code FP (or has a library for it), an FPU
>emulator should be easy to write... No FP work to be done there at all!
GCC can't open-code floating point stuff itself. We do have a
source-available floating point library based on SoftFloat and there is some
float stuff in gcc/config/fp-bit.c also.
p.
Reply to: