Path: utzoo!utgpu!attcan!uunet!lll-winken!lll-tis!helios.ee.lbl.gov!pasteur!ucbvax!ucsd!rutgers!umn-d-ub!gandreas From: gandreas@umn-d-ub.D.UMN.EDU (Glenn Andreas) Newsgroups: comp.sys.apple Subject: Re: GS/Mac toolbox "interpreting" Message-ID: <437@umn-d-ub.D.UMN.EDU> Date: 2 Aug 88 16:52:09 GMT References: <8807302312.aa12461@SMOKE.BRL.ARPA> <3258@crash.cts.com> Reply-To: gandreas@ub.d.umn.edu.UUCP (Glenn Andreas) Organization: University of Minnesota, Duluth Lines: 101 In article <3258@crash.cts.com> maddie@crash.CTS.COM (Tom Schenck) writes: >In article <8807302312.aa12461@SMOKE.BRL.ARPA> AWCTTYPA@UIAMVS.BITNET ("David A. Lyons") writes: >> [ description of the //gs toolbax call] >> [The] amount of overhead is not amazing, although it's not tiny, either. >>Usually it is small compared to the amount of time spent *in* the >>toolbox routine! >> > The toolbox routine (like ANY toolbox routine) is designed to take into > account all of the possible uses for the routine. And a lot of the time, > the routines are written to be small, and thus (usually) slower than a > routine written for a specific case. The trade-off for speed and compatablilty > (at least in my book) is obvious. Speed. The speed decrease you get by > using the toolbox routines is not worth the compatablity issue. A program > heavy on math can usually avoid the toolbox routines, but a program that > uses graphics and sound, and possibly a few special modes of graphics, > needs to use a least a FEW of the many toolbox routines. I would like to > see a game written with the toolbox. > First of all, this is a comment only regarding the Mac, as I don't know how the GS handles all of this. First of all, many of the Toolbox routines, especially the QuickDraw routines are written in hand optimized assembly. The development time spent on these things is amazing. How fast they are is even more amazing. I don't know about you, but I know that neither I nor 98% of the programmers out there could single handedly write better routines. Oh, and most games written now use the toolbox for all the appropriate routines. Granted, they need to write special routines for certain things, but every program needs to (otherwise the toolbox would contain all programs possible). Look at things like Dark Castle, Beyond Dark Castle, Crystal Quest, Deja Vu/Uninvited/Shadowgate. These are very impressive. There aren't the quantity of games that are available for an Apple II, but there are some very good one written using the toolbox, thank you very much. >>On the Macintosh, a range of 1-word opcodes is reserved; when >>executed, a "trap" to a particular vector occurs. This vector points >>to the trap dispatcher, which uses the opcode to look up the address >>of the toolbox routine to call. And if you don't like the time it take to do this, you can call GetTrapAddress which will give you the address that you can directly jump to. >>A small amount of "interpretation," if you want to call it that, is >>not a large price to pay to be able to fix toolbox bugs (by >>replacing ROM routines, etc) without needing to recompile all your >>existing applications! > >Actually, I don't see much use for the finished machine having this feature. You've haven't used a Mac much have you? >The end-user isn't going to have a way (usually) to modify the toolbox routine >that had the problem. But programmers/programs do. Apple does this to provide new features. Like scrolling menus. Like Multifinder. Macro programs. Screen savers. Every program written using MacApp (so that after x ticks of busyness the cursor turns to a watch). The list of things that patch traps is almost endless. >>You are perfectly free to bypass the toolbox. And on the mac even if you wrote the exact same code, it would be slower - ROM access is faster than RAM access. >>You will end up writing lots of code yourself that is already in the >>toolbox. You will have to do direct access to the hardware, so you >>will forfeit compatibility with future hardware revisions. > >The code that I end up writing is going to be a lot more speed efficient, and ^^^^^^^^^^^^^^^^^^^^^^^^^^ Lets see you write a faster region or polygon fill routine. I'll even put money on. $20 if you can write a faster region and polygon fill routine that can replace the ones that are in Quickdraw on the Mac. And I don't mean just handling "special cases" like the polygon being a rectangle or only fills in black - I want patterns. >also a lot more specific. Toolbox routines are generalized a great deal. This is one of the only sensable things you've said. Toolbox routines were designed to be versatile and robust. Able to handle any of the odd things that happens. That makes the system less prone to bugs and crashes. >I still hold fast to my theory that the ROM should hold a debugger (or monitor >if you preffer) and the bootstrap routine. > >Any and ALL toolbox routines should be included on a disk given out (at a small >fee of course) to end users, and as part of the developer package. The >routines included on the disk would NOT be the same routines that would have >been in ROM. They should be highly specialized, and fast. They should be >a lot of things. They should also include generalized routines, and memory- >efficient routines. And then and only then would I use a toolbox routine. Lets see. You don't want end users to all automatically have toolbox routines, they don't need them, but they should all have that built in debugger. And remember things like FFA6G to reboot. Seesh. Are you trying to say that there should be three version of all routines - one fast but specialized, one general (but slower) and one that is memory-efficient? There is some 600 or so routines documented in Inside Mac 1-5. Let's triple that. Right. > >>--David A. Lyons a.k.a. DAL Systems > >Tom Schenck, Member 52nd St Development Team =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= = "When I was young, all I wanted was to be | - gandreas@ub.d.umn.edu - = = ruler of the universe. Now that isn't | Glenn Andreas = = enough" - Alex P. Keaton | = =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=