CompuServe Messages

Keir, There is no simple answer to your questions, as different programmers have dealt with this issue in different ways. For example, Impulse chose to go the "direct" route as you've discovered. This means that their FP version has been created with in-line floating-point instructions that go straight to the hardware. When executing this instruction, the 680×0 processor generates an exception (since the instruction is not a generic 680×0 instruction). If there is a math coprocessor installed, then this exception is trapped and the coprocessor executes the instruction. This is all done via the "magic" of hardware. If there isn't a coprocessor available to handle the exception, then the program will "crash". Programmers do have other options available. First, they could assume that there is no FP coprocessor available, and hard-code their floating point calculations to use software emulation functions to do the calcs. This will work on all 680×0 processors, but will not take advantage of the coprocessor, even if it exists. For example, you could run the non-FP version of Silver on any amiga, including the 3000 (assuming there were no other bugs lurking in the program). It just wouldn't be as fast in FP calculations (although Silver is a special case, as their non-FP version is designed to rely more heavily on integer calculations). Finally, there is a third way available which is the "recommended way" (according to Commodore). Starting with WorkBench release 1.3, there is a system library in the libs: directory (mathtrans.library) that provides software functions to do the FP calculations. These functions are written to take advantage of the FP coprocessor if it is present, and to use software emulation if it is not present. The advantage here is that the same program will work whether or not you have the coprocessor, and will have a speed advantage if the processor is present. The disadvantage is that using these functions will take longer than the inline FP [ MORE ]