FSQRT tests Copyback makes a big difference on the 68040, almost doubling the speed of BASIC, but it also speeds up FSQRT. Either way, I got a speed-up of six to seven times on my 32 MHz Warp Engine Amiga 4000/040, comparing FSQRT with SQRT - although the interpreter overhead predominates in SuperBASIC if you're making one call for each iteration of a FOR loop. The boost is much more obvious in compiled tasks. This version invokes quite a lot of system code in the TRAP #0, which goes into Supervisor mode to protect the values in the floating point unit from other tasks. The whole thing goes faster and more smoothly if George Gwilt's FPSP extension is linked into Qdos or SMS, so that FPU data is swapped automatically with the other registers when Qdos swaps tasks. The overhead is relatively tiny, and the FPSP provides a consistent interface for all the 68881 and 68882 instructions, even on 68040 or 68060. FPU Functions If you want to make use of the FPU in your own programs the easiest approach is to replace the slowest floating point functions with eponymous ones that use the FPU internally. This does not speed up operators like multiplication and division, but it does boost the functions that make most use of software floating point normally. You don't get the full benefit of the FPU, because of the overhead of format conversion and checking, but the technique stays compatible with existing programs - results should be identical, but faster - and the same extensions suit original SuperBASIC and Tony Tebby's new improved SBASIC. The full FPSP is needed for my FPUFNs_CODE, a set of eleven replacements for the BASIC transcendental functions. These have no need for the TRAP #0, so they're even faster. At present they use 20 digit IEEE extended precision internally, but this seems gratuitous when Qdos only needs half that, so I'd like to hear from any users who reckon they can optimise Motorola's code to trade between speed and precision. Please contact me by Email: simon@studio.woden.com The FPSP automatically detects which tasks are using the FPU and does not need to intervene for the majority, which do not use it. But perhaps this will change, as others join George, Dave Walker and me in extending Qdos to make full use of the FPU. The FPSP is freely available, in versions for 68881 and 68882 FPUs with either 68020 or 68030 main processors (only the FPU is relevant) and much larger versions for 68040 and 68060. The 040 version is much the biggest, at almost 50K, but it does include quite a lot of routines that are not generally available in BASIC, such as hyperbolic functions and optimised logarithms for various bases. The FPSP interface for programmers is the same regardless of FPU - you just put the operands on the A7 stack and call a subroutine from a table at the start of the FPSP, which leaves the result in FP0. You'll need GWASS if you want to re-assemble any of the FPU code, which is written in 68020 assembly language, and you also need George Gwilt's FPSAVE utility to allow tasks to share the FPU safely. All these programs are available, with source, for free, but you'll need to buy your own FPU. Recent adverts in Amiga magazines offer 33 MHz 68882s for just a tenner, so the cost is not prohibitive if you've got the socket for it already. In the case of the 68040 and 68060 the full version of the chip fits the same socket as the EC version with no FPU, so you'll end up with a spare 'EC' chip after making the substitution. You should still be very careful not to bend any of the 200 or so pins in the course of swapping the parts; it might be worth buying a 'PGA chip puller' tool to reduce this risk. I'm surprised how many QXL owners have already done this, just to speed up the integer performance of their machines. Acid tests Here are test timings of FPUfns 1.2 on an Amiga 4000/030 with 68882, Thierry Godefroy's 32 MHz QXL with XC68040, George Gwilt's standard speed 20 MHz QXL (expanded with a full 68040) and my 50 MHz A4000/060. 030/25 040/32 040/20 060/50 SIN 1142 % 307 % 544 % 300 % COS 3138 % 391 % 575 % 318 % EXP 1105 % 1180 % 658 % 372 % SQRT 1200 % 400 % 1905 % TAN 1030 % 792 % 1053 % 351 % COT 944 % 914 % ATN 1065 % 569 % 272 % ASIN 1574 % 503 % 549 % ACOS 1497 % 500 % 427 % LN 748 % 468 % LOOG10 880 % 419 % The first columns shows the time for a 25 MHz 68030 with a 20 MHz FPU - a 68882. We shall also test the code on a 68020+68881 combination, but there are no results for that configuration yet. It should be at least half as good as the 68030 figure, depending on relative clock speeds; the boost is greatest with a separate FPU, but that's misleading as the integer unit is relatively slow, giving the FPU an advantage, and the built-in 68040 and 68060 FPUs work best when given a steady stream of code to process, rather than just the odd instruction in a sea of integer operations. For this reason C68 is expected to show the most impressive performance boost on 68040 and 68060 processors. The 68060 tests used the 68040 FPSP, as the 68060 version was not ready in time. It works with the 68040 version, but the code is longer and slower than necessary. The results vary depending on the range of values used. Thierry's test program used much bigger values than expected, which is why it crashed at COT. I've since added a range test to reject values that SuperBASIC would not permit anyway, and the checks on EXP, ASIN and ACOS seem to be watertight. SQRT took so little time on George's 20 MHz QXL that it gave a meaningless negative 'speed-up' factor over 20,000 iterations. SBASIC is a lot faster than SuperBASIC, which makes the loop overhead much less significant. SuperBASIC users often compile their code to avoid delays caused by Sinclair's slow interpreter, and if you do that the FPU functions give proportionally much more benefit. Even so, they only speed up the eleven functions listed, and while they're among the slowest on the QL - though still VERY fast compared with other 'eight bit' micros - you won't see any benefit unless your programs use those functions!