Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!thunder.mcrcim.mcgill.edu!snorkelwacker.mit.edu!shelby!msi.umn.edu!noc.MR.NET!gacvx2.gac.edu!gacvx2.gac.edu!scott From: scott@erick.gac.edu (Scott Hess) Newsgroups: comp.sys.next Subject: Re: 68040 Math: Emulation or library call or inline code ? Message-ID: Date: 18 Feb 91 15:07:02 GMT References: <1991Feb14.160749.19048@batcomputer.tn.cornell.edu> <290@rosie.NeXT.COM> <1991Feb15.135340.2808@news.sara.nl> <1991Feb17.113656.5876@kithrup.COM> <1991Feb18.105109.2810@news.sara.nl> Organization: Gustavus Adolphus College Lines: 49 Nntp-Posting-Host: erick.gac.edu In-reply-to: toon@news.sara.nl's message of 18 Feb 91 09:51:09 GMTLines: 49 In article <1991Feb18.105109.2810@news.sara.nl> toon@news.sara.nl writes: Well, that depends on how this is implemented. I can imagine that in the old ('030) case, sin(), cos(), tan() and friends translated to either a single instruction library call, or a single instruction expanded inline (although I don't know enough of the (gcc) compiler to know whether it is _possible_ to translate library calls to inline code). If this _is_ possible you have the choices (for the '040) to either translate to a library call (with the library routine containing the 'emulation' code) or to expand the 'emulation' code inline. Note that the reason for this - although it amounts to more code - is that it is faster. Either of the two possibilities is faster than heaving the instructions emulated by traps, because in that case you also have to execute the trap code itself. I'm fairly sure that real fsin/cos instructions were generated by the compiler - no need for the library routines when using 68882, as the coprocessor was smart enough for it. The main problems with traps isn't so much the trap code as the requirement to save everything in sight so you can continue where you left off when you get back. Well, the trap code isn't wanted, either, of course :-). I think that the idea of using library calls is good. That's one of the ideas of stdio - without doing system calls, you cut down on the number of traps, and the code executes faster when it's entirely in user-mode, rather than having to switch to supervisor so often. If worst comes to worst, the '030 version will be slowed down. But, I submit the fact that within a couple months, there will more than likely be more '040 machines out there than '030 machines. Also, sad but true, the '030 is the architecture of the past for NeXTs. I mean, I still use '030 machines for almost all of my work, because there aren't enough here yet to make a difference, but I'm more concerned that my code be faster on the machines that I _will_ be running on than about the machines I _was_ running on. Besides, I suspect this is all currently academic. From what I've heard, the current trap stuff is sort of slow, anyhow, at least compared to what it could be. Sigh. Later, -- scott hess scott@gac.edu Independent NeXT Developer GAC Undergrad "Tried anarchy, once. Found it had too many constraints . . ." "Buy `Sweat 'n wit '2 Live Crew'`, a new weight loss program by Richard Simmons . . ."