Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!mips!decwrl!deccrl!bloom-beacon!eru!hagbard!sunic!mcsun!ukc!edcastle!aiai!aipna!awb From: awb@uk.ac.ed.aipna (Alan W Black) Newsgroups: comp.os.minix Subject: Floating point support in GCC Message-ID: Date: 15 Apr 91 13:29:12 GMT Sender: news@aipna.ed.ac.uk Organization: Dept of AI, Edinburgh University, UK Lines: 62 In-reply-to: dhinds@elaine1.Stanford.EDU's message of 14 Apr 91 18:41:08 GMT In article awb@uk.ac.ed.aipna (Alan W Black) writes: > >Much of the gnu software has been ported to MINIX 386. Currently on >plains.nodak.edu (134.129.111.64 in pub/Minix/uk). This is includes >binaries and patchs for gcc1.37.1 gas, the bin utilities, patches to >the MINIX libraries. There is also a port of gnu emacs 18.55 (which >contains a rather nasty bug regarding killing of sub-processes. I've >since fixed this and I can send you a new set of patches if you want). >The gcc *does* support floating point but not in a very efficient way. What sort of floating point support is this? I'm new to Minix, but I'm told the regular C compiler doesn't do floating point at all. Does the gcc port support coprocessor emulation, or does it need a coprocessor? In what way is it inefficient? Is there a reasonably standard libm? -David Hinds dhinds@cb-iris.stanford.edu GCC supports floating point. The machine description for the 386 is such that GCC on a 386 can generate 387 code, or call soft functions that emulate it. In our actual implementation we use the distributed 386 description which unfortunately still generates some 387 instructions even when -msoft-float (the default) is used. Basically it will call software functions to do the floating point but expects to pass its arguments and receive its result via a register on the 387. As we don't have a 387 we got round the porblem as follows. When code is linked, a floating point exception handler is also linked in. When a 387 instruction is executed and the handler is called the instruction is emulated. This does work but is not at all fast, though as it is only for a very small number of instructions it doesn't get called very often. The correct solution to the problem is to modifiy the GCC 386 machine description so that it never generates any 387 instructions. This might be trivial for someone who understands machine descriptions but we don't and haven't tried to do it -- if anyone knows how to do this please let me know. I am not sure how this would work if you actually have a 387. I suspect you could recompile gcc without -msoft-float and it would then generate 387 instructions, then do not load the floating point handler and it should work. I should add that we only support doubles rather than floats because we didn't write the appropriate functions for floats only doubles so that you sometimes need to #define float double to make some pieces of code work. The rest of the floating point code (libm.a) is from Fred Fish's portable math library, which is available from atari.archive.umich.edu (141.211.164.8 in atari/gnustuff/minix). We find this quite adequate for all our floating point stuff (prologs scheme's and lisp). We include a compiled version if this library in our distribution on plains. Alan Alan W Black 80 South Bridge, Edinburgh, UK Dept of Artificial Intelligence tel: (+44) -31 650 2713 University of Edinburgh email: awb@ed.ac.uk