[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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.


Reply to: