Path: utzoo!attcan!uunet!tektronix!percival!parsely!agora!billsey From: billsey@agora.UUCP (Bill Seymour) Newsgroups: comp.sys.amiga Subject: Re: CMI Board and Absoft FORTRAN? Message-ID: <1391@agora.UUCP> Date: 2 Mar 89 23:27:13 GMT References: <640@boing.UUCP: Organization: Advanced Solutions, Hillsboro, OR Lines: 89 From article <640@boing.UUCP:, by dale@boing.UUCP (Dale Luck): : In article <1381@agora.UUCP: billsey@agora.UUCP (Bill Seymour) writes: : = The man you need to talk to is Larry Gutkowski. His address (from the : =PA Utilities disk) is: : : an address in Vancouver Wash, irrelevant for this followup : = : = I know he has the library for sale, but I don't know how much he's : =asking for it. He's done quite a bit better job of handling a peripheral : =device type '881 than C= has done with the 1.3 IEEE libraries, so it's well : =worth the investment. (IS there anyone out there who's re-compiled ASPICE : =for '881 support yet?) : : Would you please provide some specific examples? Where is the C= library : lacking? Is there a performance difference? Can they multitask? Is the : installation any more difficult? Does the cmi library work with a : 68020/68881 combination? I'm pretty much working from what Larry has told me here, so bear with me... (I'm not a programmer in general, much less a FORTRAN programmer...) I believe the main thing he ran into with the current IEEE libraries was the lack of support for single precision. This is one of the things that I know you are addressing in 1.4, but for right now... I've gotten a lot of calls from people who can't match the performance of Larrys benchmarks using 'C' and the IEEE libraries. I don't know for sure whether this is just indicative of the differences between C and FORTRAN, or whether it's his library. My guess is that it's a combination. His libraries aren't multitasking by themselves, for that you need something like the fpu.library that Perry Kivolowitz wrote for us at CMI. The fpu.library is distributed with all PAs on the utilities disk. It works well with all the C programs that use the IEEEs also. Larrys libraries are installed into the software at compile time, rather than having a seperate library on the disk. That gives you larger code and you have to compile a version seperately for 68881/68000 support. But right now, it's the *only* way to get 68881 peripheral support using Absoft FORTRAN. If you are compiling for a 68020/68881 combination, you are much better off to go ahead and use the compile switch from Absoft, since I don't believe that Larrys routines will work in that environment. Maybe he'll see this posting and give more info. (I don't know if he has Usenet access...) : The last is not a completely an irrelevant question even if : cmi does not sell an 020/881. The question was meant bring out a point : though. You see C= does not sell a memory mapped 881 device either yet : they support it with their libraries. : The design of the peripheral 68881 interface was set up so that : the libraries were a convenience for programmers that did not want to : deal with the details of software vs 68000/68881 vs 68020/68881, : however since the multitasking support is a required piece of software : that the vendor must provide, this means that and application does not : have to use the libraries to get at the 68881. This application should : be able to multitask with applications that do use the ieee libraries. There's is no doubt that the IEEE route is the way to go for the future. It works out for the best for both the programmer/software company and for the hardware company to have one standard version that will work well for any means of accessing a math chip, as well as for those people who still don't have math chips. I personally hope that the changes that are coming in 1.4 make it feasable for *every* piece of software that does math to be compiled for IEEE. Right now, there's a performance loss for people who are using integer math if they compile to use IEEE. They have to convert to double precision and in the end there is still a speed *loss* possible under a 68000/68881 environment. I have an example of this, the PD (shareware?) ray tracing program, URay, from Dave Wecker. When compiled to *not* use the math chip (In this case, for single precision) I get faster render times on the demo pictures than when compiled to use the math chip (Double precision). The code is Manx code, and my version of the 1.4 IEEEs don't yet have the .lib stuff, so I haven't been able to try it out with the new stuff. I imagine that the new single precision stuff will remove all disadvantages... : Ok, I'll go back to my cave now. But, it's so nice and sunny out here! :-) : But I still want to know what the problems are with the 1.3 ieee libraries. : We are working on upgrades for V1.4 and want to know what the problems : are. I'll try and see if I can get Larry to expound further on what he's seen. I seem to remember something about some transendental functions he was supporting that weren't in the 1.3 IEEEs also... : -- : Dale Luck GfxBase/Boing, Inc. : {uunet!cbmvax|pyramid}!amiga!boing!dale -- -Bill Seymour ...tektronix!reed!percival!agora!billsey ...tektronix!sequent!blowpig!billsey Creative Microsystems Northwest Amiga Group At Home Sometimes (503) 691-2552 (503) 656-7393 BBS (503) 640-0842