bparsia@eagle.wesleyan.edu (03/26/90)
Perhaps some of you with more experience with object-oriented programming (OOP) will comment. Someone mentioned in another post in another group (the post part of the "why can't Apple ][ users accept the mac" thread) that the bewildering variety of Macintoshs has lead to an unacceptable set of conditions one must check and take into account when programming. Color QuickDraw is one example of such a condition. I was wondering what could be done to simplfy programming on the Mac for everyone except the ROM and system programmers (sorry, someone has to suffer). Some things (like CQD) have to be taken care of by the appl. programmer (if you are writing a color paint package, you'd better make the color calls), but other conditions should be transparant, as far as possible, to the "end" programmer. For example, numeric coprocessors. THINK Pascal (along with most other packages I hope) has a 68881 compile option which generates optimized code for the coprocessor if you check it off. Now, why doesn't Apple just set up a standard numeric enviroment (i.e. SANE), included in the system or the ROM, written in blazingly fast and clever assembly language, and tailored to each machine. Thus the SANE in the SE ROM would just use the 68K to do the work, while the SANE in the II series would be optimized for the coprocessor. The upshot is: both have the same interface, allowing one to do the coding once, and each implementation in the ROM (or the system, whatever) would take care of making the call in the best possible way for that system. No mess, no fuss, on compile and the program is oblivious to the differences (the user isn't, there is just one version of the program and it runs great). Now, take the idea a step further. What if Apple implemented a MacApp type class library and stuck *it* in the ROMS, optimized (of course) for the particular machine. Thus the MacApp II in the II ROMs could take advantage of the nifty '020 features, the MacApp IIci in the IIci ROMs could take advantage of *its* nifty features (burst mode something or other, etc.), the the MacApp IIfx in the IIfx ROMs could take advantage of its nifty features--features which now (I believe) are up to the individual programmers to figure out and use. The advantage: Consistently high quality code, tailored to the special features of each machine. Guarranteed optimal performance. More pros: If you put it on fast ROMs, the processor wouldn't need as large a cache or as clever progamming to reach zero wait states. The end programmer binaries would be quite small in many cases (except where the programmer did extensive alteration of the classes, but even then, programs would mainly be a series of calls to the ROM). Better code compatibility--as long as you keep the interface basically the same, the progams will run). Along with that, a greater degree of hardware independance. More application consisitency--if the human interface is in the ROMs, and will both lower one's application size and improve (in most cases) performance *and* insure (almost) complete compatibility with now and future machines, people will use it. Cons: A hell of a lot of work for apple, but it would generate good software and sell machines. I think there are more advantages, but this post is long enough. I invite comments. Is this scheme possible, practical, silly? Other cons, other advantages, dissenting views; all are desired. Bijan J. Parsia
siegel@endor.harvard.edu (Rich Siegel) (03/26/90)
In article <13828@eagle.wesleyan.edu> bparsia@eagle.wesleyan.edu writes: >Perhaps some of you with more experience with object-oriented programming (OOP) >will comment. > >Someone mentioned in another post in another group (the post part of the "why >can't Apple ][ users accept the mac" thread) that the bewildering variety of >Macintoshs has lead to an unacceptable set of conditions one must check and >take into account when programming. Color QuickDraw is one example of such a >condition. I was wondering what could be done to simplfy programming on the Mac >for everyone except the ROM and system programmers (sorry, someone has to >suffer). Some things (like CQD) have to be taken care of by the appl. It's true that in some cases you must check for specific functionality, but only if you're going to require that functionality in order for the program to run. For example, I don't care whether Color Quickdraw exists if I'm writing a compiler, and my text editor doesn't care what kind of video cards the Mac II has in it. In the general case, a Mac program can get by with not checking for specific functionality and run on all Macs. >For example, numeric coprocessors. THINK Pascal (along with most other packages >I hope) has a 68881 compile option which generates optimized code for the >coprocessor if you check it off. Now, why doesn't Apple just set up a standard >numeric enviroment (i.e. SANE), included in the system or the ROM, written in >blazingly fast and clever assembly language, and tailored to each machine. Thus >the SANE in the SE ROM would just use the 68K to do the work, while the SANE in >the II series would be optimized for the coprocessor. The upshot is: both have In fact, that's exactly the way it's done. SANE on the Mac II is faster than SANE on a Portable (for example). However, SANE is tailored to conform to the IEEE P784 spec for accuracy, and not so much for performance; you do pay a little overhead for the trap dispatch, for the fact that SANE only takes arguments by address on the stack, and for that extra accuracy. Direct '881 calls are much faster than going through SANE, but are occasionally less accurate. > >Now, take the idea a step further. What if Apple implemented a MacApp type >class library and stuck *it* in the ROMS, optimized (of course) for the > >Cons: A hell of a lot of work for apple, but it would generate good software >and sell machines. Another con: it would be nearly impossible to maintain and update. R. ~~~~~~~~~~~~~~~ Rich Siegel Staff Software Developer Symantec Corporation, Language Products Group Internet: siegel@endor.harvard.edu UUCP: ..harvard!endor!siegel "When someone who makes four hundred and fifty dollars an hour wants to tell you something for free, it's a good idea to listen." ~~~~~~~~~~~~~~~
philip@Kermit.Stanford.EDU (Philip Machanick) (03/27/90)
In article <2346@husc6.harvard.edu>, siegel@endor.harvard.edu (Rich Siegel) writes: > In article <13828@eagle.wesleyan.edu> bparsia@eagle.wesleyan.edu writes: > > >For example, numeric coprocessors. THINK Pascal (along with most other packages > >I hope) has a 68881 compile option which generates optimized code for the > >coprocessor if you check it off. Now, why doesn't Apple just set up a standard > >numeric enviroment (i.e. SANE), included in the system or the ROM, written in > >blazingly fast and clever assembly language, and tailored to each machine. Thus > >the SANE in the SE ROM would just use the 68K to do the work, while the SANE in > >the II series would be optimized for the coprocessor. The upshot is: both have > > In fact, that's exactly the way it's done. SANE on the Mac II is > faster than SANE on a Portable (for example). However, SANE is tailored to > conform to the IEEE P784 spec for accuracy, and not so much for performance; > you do pay a little overhead for the trap dispatch, for the fact that > SANE only takes arguments by address on the stack, and for that extra > accuracy. Direct '881 calls are much faster than going through SANE, but > are occasionally less accurate. > I benchmarked the cost of going through SANE on a Mac II a while back, using a program to draw a nice Mandelbrot set picture on a 19" screen. The direct calls were about 18 times faster than going through SANE (using Think Pascal 2). Is this the cost of trap dispatching? It might be interesting to do the benchmark again, doing direct calls to ROM - should not be worse than 4-5 times slower than going direct to the 68881. Of course, the vast majority of Mac aps are not this FP-intensive, but the point is that the cost of the standard mechanism is too high for some applications - hence the appearance of model-specific software (e.g., Mathematica). Philip Machanick philip@pescadero.stanford.edu
minich@a.cs.okstate.edu (MINICH ROBERT JOHN) (03/27/90)
From article <13828@eagle.wesleyan.edu>, by bparsia@eagle.wesleyan.edu: > Someone mentioned in another post in another group (the post part of the "why > can't Apple ][ users accept the mac" thread) that the bewildering variety of > Macintoshs has lead to an unacceptable set of conditions one must check and > take into account when programming. Color QuickDraw is one example of such a > condition. I was wondering what could be done to simplfy programming the Mac > for everyone except the ROM and system programmers (sorry, someone has to > suffer). Some things (like CQD) have to be taken care of by the appl. > programmer (if you are writing a color paint package, you'd better make the > color calls), but other conditions should be transparant, as far as possible, > to the "end" programmer. > > For example, numeric coprocessors. THINK Pascal (along with most other > packages I hope) has a 68881 compile option which generates optimized code > for the coprocessor if you check it off. Now, why doesn't Apple just set up a > standard numeric enviroment (i.e. SANE), included in the system or the ROM, > written in blazingly fast and clever assembly language, and tailored to each > machine. Thus the SANE in the SE ROM would just use the 68K to do the work, Ah, a nice sentiment, but there's one prob! To a certain extent, the SANE on a 6888x machine does use the math chip. (Could be a bit more, bue Apple's software is just barely more ccurate on some transcendental routines.) The reason why this will never be as good as the FP options on the compilers is that you have the overhead of a procedure call for each operation yo perform. Imagine writing a bunch of one line functions like double my_add( double a, double b) {...} for all the basic FP math you do. I think if you run thisthrough a profiler, you'll find way way too much time spent on calling routines rather than crunching numbers. This is what SANE does now, so you can probably guess that any app using FP math on the heavy side is probably going to be better off calling the chip directly. Otherwise, your app _alread_ will use the math chip for SANE routines! The other prob with transparent FP chip use is that the formats for SANE and the 6888x are of different sizes, and you have to do byte crunching to transfer them back and forth. That's more overhead on the routines, since everyone will expect the SANE format results! This is certainly best left to the compiler to use the direct FP calls and figure out who needs what beforehand, avoiding all the ugly delays with format swapping and routine calling. Orders of magnitude difference! If you want the easiest way out, compile your app in two versions, one with FP, one without. If you have only a few routines that will REALLY benefit from the boost, compile a version of them with FP calls to the chip and one without. Convert the values where necessary and at runtime, use whatever is appropriate. (Simply said, a bit more work in the code, though.) > Now, take the idea a step further. What if Apple implemented a MacApp type > class library and stuck *it* in the ROMS, optimized (of course) for the > particular machine. Thus the MacApp II in the II ROMs could take advantage of > the nifty '020 features, the MacApp IIci in the IIci ROMs could take advantage > of *its* nifty features (burst mode something or other, etc.), the the MacApp > IIfx in the IIfx ROMs could take advantage of its nifty features--features which > now (I believe) are up to the individual programmers to figure out and use. > > The advantage: Consistently high quality code, tailored to the special features > of each machine. Guarranteed optimal performance. > > More pros: If you put it on fast ROMs, the processor wouldn't need as large a > cache or as clever progamming to reach zero wait states. > The end programmer binaries would be quite small in many cases (except > where the programmer did extensive alteration of the classes, but even then, > programs would mainly be a series of calls to the ROM). Better code > compatibility--as long as you keep the interface basically the same, the > progams will run). Along with that, a greater degree of hardware independance. > More application consisitency--if the human interface is in the ROMs, and will > both lower one's application size and improve (in most cases) performance *and* > insure (almost) complete compatibility with now and future machines, people > will use it. > > Cons: A hell of a lot of work for apple, but it would generate good software > and sell machines. > I will shoot my foot if Apple does what you ask here. I'll then turn and shoot you! If you're going to put it in ROM, either it better not change anytime soon or the ROM changes better be easy and quick. (And cheap 8-|) Something like MacApp is not perfect and error free and never will be. Putting it in ROM will force you to write to that old version, stuck in time. What do you do when the new MacApp ROMS come out? Do you write to the new version or the old, sans the new features? Imagine having to tell a customer that your program runs only with the new ROMs, so they have to go out and upgrade. No doubt Apple will have a nice fee for this changeout. No, what you've hit on that could be a much more useful and elegant idea is that of _sharing_ common code, like MacApp. If you look over some PC type shoulders, you'll see that this is one of the features of OS/2. When you're program starts up (maybe even while it's running), you can open a library and use it's routines. You don't have to compile them all into your program! The benefits are real handy, too. You drop the size of your programs (overall) by sharing code. Not just source code, but the executables. You can use libraries provided by, say, Apple to do nifty things without the obliqueness of some sort of trap dispatch style implementation. (Not to mention that not everyone get's to use these reserved routines! ;-) ) This is pretty similar to something like cdevs and XCMDs et al. But with that sort of linking, you do all the work of something than an OS should do. I guess maybe we'll see this in Sys 8.0? PLEASE, Apple? (I want protected memory before that, tho. I want it NOW, but I think we need it ASAP...too many Macs crash when someone does somthing stupid in their INIT or app and takes out a whole system. That'll be just great with virtual memory and bunches of apps running with huge documents. It would only take 5 minutes to reboot after that...of course, you may miss all that data you were working with... but i digress.) So, Apple. Please send dynamic linking our way. I really don't think it can be all _that_ difficult. All the compilers can link. Why not the OS? Back to the original post.... > I think there are more advantages, but this post is long enough. > Bijan J. Parsia Well, this post is too long.... But I think I've managed to cover all your points! Robert Minich minich@a.cs.okstate.edu Has you Mac crashed this week? today? in the last hour? 5 minutes ago? As I....
ken@wj.msc.umn.edu (Ken Chin-Purcell) (03/27/90)
In article <1990Mar26.180116.8814@Neon.Stanford.EDU>, philip@Kermit.Stanford.EDU (Philip Machanick) writes: > I benchmarked the cost of going through SANE on a Mac II a while back, using > a program to draw a nice Mandelbrot set picture on a 19" screen. The direct > calls were about 18 times faster than going through SANE (using Think > Pascal 2). Another data point, using MPW Pascal 2.0: I wrote a commercial MacApp program for mechanism synthesis. Parts of this program were very numericaly intensive, including sqrt() and trig functions, while other parts did mostly tree building, searches, and drawing. I would suspect that most CAD programs have a similar balance of integer/real/drawing computations. When changing the 'design curves', which involves both calculations and drawing on the fly, the relative speeds came out to be: Mac II, direct 68881 calls ....... 1.0 Mac II, SANE calls ............... 2.0 Mac Plus, SANE calls ............ 10.0 ||| Ken Chin-Purcell ||| also known as ken@msc.umn.edu and (612) 626-1340 ||| Minnesota Supercomputer Center, University of Minnesota
philip@Kermit.Stanford.EDU (Philip Machanick) (03/28/90)
In article <5492@okstate.UUCP>, minich@a.cs.okstate.edu (MINICH ROBERT JOHN) writes: > Ah, a nice sentiment, but there's one prob! To a certain extent, the > SANE on a 6888x machine does use the math chip. (Could be a bit more, > bue Apple's software is just barely more ccurate on some transcendental > routines.) The reason why this will never be as good as the FP options > on the compilers is that you have the overhead of a procedure call for > each operation yo perform. Imagine writing a bunch of one line functions > like double my_add( double a, double b) {...} for all the basic FP > math you do. I think if you run thisthrough a profiler, you'll find way > way too much time spent on calling routines rather than crunching > numbers. This is what SANE does now, so you can probably guess that any > app using FP math on the heavy side is probably going to be better off > calling the chip directly. Otherwise, your app _alread_ will use the > math chip for SANE routines! > The other prob with transparent FP chip use is that the formats for > SANE and the 6888x are of different sizes, and you have to do byte > crunching to transfer them back and forth. That's more overhead on the > routines, since everyone will expect the SANE format results! > This is certainly best left to the compiler to use the direct FP calls > and figure out who needs what beforehand, avoiding all the ugly delays > with format swapping and routine calling. Orders of magnitude > difference! If you want the easiest way out, compile your app in two > versions, one with FP, one without. If you have only a few routines that > will REALLY benefit from the boost, compile a version of them with FP > calls to the chip and one without. Convert the values where necessary > and at runtime, use whatever is appropriate. (Simply said, a bit more > work in the code, though.) Question: Does execution of a 68881 instruction on a 680x0 without a 68881 cause an invalid instruction trap (something not too strange to the Mac)? If the answer is yes, here's an alternative solution: software emulation of the 68881. The cost of such software emulation on Macs without the chip would surely be no higher than SANE calls, whereas the cost of NOT using the 68881 directly can be unacceptably high. The only problem remaining to be solved is whether to continue to support more accurate transcendentals as supported by SANE (longer-term: Apple could phase out SANE, with minimal support for obsolete products, something like System 4.0). > ... No, what you've hit on that could be a much more useful and elegant > idea is that of _sharing_ common code, like MacApp. If you look over > some PC type shoulders, you'll see that this is one of the features of > OS/2... > So, Apple. Please send dynamic linking our way. I really don't think > it can be all _that_ difficult. All the compilers can link. Why not the > OS? > There is a trade-off here. Dynamic linking costs you every time you launch; traps cost you every time you do a call. In many cases the latter is perceived to be faster (though it isn't) because you don't have to wait as long at one specific time. How long does an OS/2 app take to launch? As long as the MPW linker takes to link? I think there's a case for supporting both: Apple allows you to kludge a sort of dynamic link by getting a trap address and doing a subroutine branch to it, but a cleaner mechanism would be attractive. You could then specify specific performance-critical routines should be "dynamically linked", whereas others could go through the trap mechanism. Philip Machanick philip@pescadero.stanford.edu
des7f@uvacs.cs.Virginia.EDU (David Sappington) (03/29/90)
[ much discussion of using SANE vs. direct calls to the FPU ] Shipping a floating point intensive application that doesn't have a version using direct calls to the FPU should be a crime!! Why oh why doesn't Apple include a 6888x emulation package with their system software? Just as the Mac's trap dispatcher handles Axxx "instructions", Apple could easily set up a dispatcher to handle the Fxxx floating point "instructions" on machines w/o an FPU. Everyone could then use direct calls to the FPU and still have their programs run on a Plus or SE. 68020 instructions that are not available on the 68000 could also be emulated by using the "illegal instruction" trap but I don't know if it would be worth doing. Dave Sappington des7f@virginia.edu Institute for Parallel Computation des7f@virginia.BITNET University of Virginia
rcfische@polyslo.CalPoly.EDU (Raymond C. Fischer) (03/29/90)
In article <1169@ra.cs.Virginia.EDU> des7f@uvacs.cs.Virginia.EDU (David Sappington) writes: >[ much discussion of using SANE vs. direct calls to the FPU ] > >Why oh why doesn't Apple include a 6888x emulation package with their >system software? Just as the Mac's trap dispatcher handles Axxx >"instructions", Apple could easily set up a dispatcher to handle the >Fxxx floating point "instructions" on machines w/o an FPU. Everyone >could then use direct calls to the FPU and still have their programs >run on a Plus or SE. Good idea. Perhaps with a different interface, SANE would even become slightly faster. Programs would certainly be smaller since 68882 instructions are smaller than equivalent SANE traps. >68020 instructions that are not available on the 68000 could also >be emulated by using the "illegal instruction" trap but I don't know >if it would be worth doing. Not possible. In addition to a few new instructions, the 68020 also has new addressing modes which do not generate illegal instruction traps, but rather just cause general mayhem when used on a 68000. Ray Fischer rcfische@polyslo.calpoly.edu
keith@Apple.COM (Keith Rollin) (03/29/90)
In article <261189c1.4ce@polyslo.CalPoly.EDU> rcfische@polyslo.CalPoly.EDU (Raymond C. Fischer) writes: > >In article <1169@ra.cs.Virginia.EDU> des7f@uvacs.cs.Virginia.EDU (David Sappington) writes: >>[ much discussion of using SANE vs. direct calls to the FPU ] >> >>Why oh why doesn't Apple include a 6888x emulation package with their >>system software? Just as the Mac's trap dispatcher handles Axxx >>"instructions", Apple could easily set up a dispatcher to handle the >>Fxxx floating point "instructions" on machines w/o an FPU. Everyone >>could then use direct calls to the FPU and still have their programs >>run on a Plus or SE. > >Good idea. Perhaps with a different interface, SANE would even become >slightly faster. Programs would certainly be smaller since 68882 >instructions are smaller than equivalent SANE traps. I don't know if this solution would result in faster code. There are a LOT of instructions that would have to emulated. Not just things like FCOS or FSUB or FLOG2. But you would also have to emulate all of the FMOVE instructions. These FMOVE instructions would have to go through a rather elaborate trap dispatcher, which would add a lot to execution time. I suppose, on the other hand (I love arguing with myself), that FMOVE instructions could be optimized in the dispatcher, and handled rather quickly. So where does the memory for the FP registers come from. Low memory? Sounds possible. Are there any other problems that need to be hurdled? The 6888x raises exceptions; would there be any problem with emulating these? -- ------------------------------------------------------------------------------ Keith Rollin --- Apple Computer, Inc. --- Developer Technical Support INTERNET: keith@apple.com UUCP: {decwrl, hoptoad, nsc, sun, amdahl}!apple!keith "Argue for your Apple, and sure enough, it's yours" - Keith Rollin, Contusions
nebel@wam.umd.edu (Chris D. Nebel) (03/30/90)
In article <261189c1.4ce@polyslo.CalPoly.EDU> rcfische@polyslo.CalPoly.EDU (Raymond C. Fischer) writes: >In article <1169@ra.cs.Virginia.EDU> des7f@uvacs.cs.Virginia.EDU (David Sappington) writes: >>Why oh why doesn't Apple include a 6888x emulation package with their >>system software? Just as the Mac's trap dispatcher handles Axxx >>"instructions", Apple could easily set up a dispatcher to handle the >>Fxxx floating point "instructions" on machines w/o an FPU. Everyone >>could then use direct calls to the FPU and still have their programs >>run on a Plus or SE. Supposedly, this has actually been done. There was a news bit in Byte magazine a month or two back about a program called XMath by some German company that provided software emulation of 68881 and 68020 instructions on a 68000. The hitch is that they didn't give any way to contact them: no address, no phone number, nothing. Also, they didn't say whether it was actually finished or just "Real Soon Now". Does anyone know where to find these people? >Good idea. Perhaps with a different interface, SANE would even become >slightly faster. Programs would certainly be smaller since 68882 >instructions are smaller than equivalent SANE traps. They claimed in the article a speedup of about 5x over normal SANE. >>68020 instructions that are not available on the 68000 could also >>be emulated by using the "illegal instruction" trap but I don't know >>if it would be worth doing. > >Not possible. In addition to a few new instructions, the 68020 >also has new addressing modes which do not generate illegal instruction >traps, but rather just cause general mayhem when used on a 68000. Well, they claimed that they'd done it, but they could just be misreporting things... :) Chris Nebel nebel@wam.umd.edu
chewy@apple.com (Paul Snively) (03/30/90)
In article <261189c1.4ce@polyslo.CalPoly.EDU> rcfische@polyslo.CalPoly.EDU (Raymond C. Fischer) writes: > >68020 instructions that are not available on the 68000 could also > >be emulated by using the "illegal instruction" trap but I don't know > >if it would be worth doing. > > Not possible. In addition to a few new instructions, the 68020 > also has new addressing modes which do not generate illegal instruction > traps, but rather just cause general mayhem when used on a 68000. > > > Ray Fischer > rcfische@polyslo.calpoly.edu To make matters worse, the exception stack frame is different between the 68000 and 68020, as anyone who's ever worked on a Mac debugger knows. ;-) __________________________________________________________________________ Paul Snively Macintosh Developer Technical Support Apple Computer, Inc. 1st Choice: Paul_Snively.DTS@qm.gateway.apple.com 2nd Choice: CHEWBACCA@applelink.apple.com Last Choice: chewy@apple.com Just because I work for Apple Computer, Inc. doesn't mean that I believe what they believe, or vice-versa. __________________________________________________________________________