AWCTTYPA@UIAMVS.BITNET ("David A. Lyons") (08/01/88)
>Date: Mon, 25 Jul 88 04:32:26 GMT >From: Tom Schenck <ucsdhub!hp-sdd!ncr-sd!crash!maddie@UCSD.EDU> >Subject: Re: If the GS meant business... >Yes, I quite no the difference between hardware and software. The >//gs IS built to simulate the 68000 environment as much as possible. The IIgs toolbox is designed to support a Desktop-based environment (menus, windows, etc) that strongly resembled the Macintosh desktop-based environment. This environment has nothing to do with the 68000. If you mean by "simulate" that the IIgs desktop environment is any less "real" than the Macintosh desktop environment, I disagree. >I have never really like[d] the //gs OR the Mac (ANY of them) for any >serious programming work. Why? Because everything you do, even if you >write it in straight machine code, goes through an intepreter. The OS >on the //gs and the mac has just too much overhead, and is to[o] >high-level for me to ever consider it as a serious programming >machine. I assume you're talking about the Macintosh "trap dispatcher" and the IIgs "tool dispatcher." You may want to call these interpreters, but they interpret only TOOLBOX CALLS, not the rest of your machine code. I'm most familiary with the IIgs. The tool dispatcher is called through a fixed address, with a 16-bit tool/function code in a CPU register. The tool dispatcher performs two table lookups to find the address of the toolbox function to call. First it uses the toolset number in the 16-bit code to look up a subtable of addresses for the toolset being called. Then it uses the function number to look up the address of the actual function in the subtable. 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! 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. 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! >If you would like to provide me with a way to bypass the toolbox to >do operations, I'd be happy to start programming on the Mac again. I >d[e]spise having to depend on Toolbox routines to do things. I like >the convinence, but I would like to be able to NOT use them if I can. You are perfectly free to bypass the toolbox. 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. >UUCP: {cbosgd, hplabs!hp-sdd, sdcsvax, nosc}!crash!pnet01!maddie >ARPA: crash!pnet01!maddie@nosc.mil >INET: maddie@pnet01.CTS.COM >Tom Schenck, member 52nd Street Development Team. --David A. Lyons a.k.a. DAL Systems PO Box 287 | North Liberty, IA 52317 BITNET: AWCTTYPA@UIAMVS CompuServe: 72177,3233 GEnie mail: D.LYONS2
maddie@crash.cts.com (Tom Schenck) (08/02/88)
In article <8807302312.aa12461@SMOKE.BRL.ARPA> AWCTTYPA@UIAMVS.BITNET ("David A. Lyons") writes: > >The IIgs toolbox is designed to support a Desktop-based environment >(menus, windows, etc) that strongly resembled the Macintosh >desktop-based environment. This environment has nothing to do with >the 68000. > >If you mean by "simulate" that the IIgs desktop environment is any >less "real" than the Macintosh desktop environment, I disagree. > The //gs has something called "phantom slots" hard wired into the system, and also has a limited instruction trapping routing included in the hardware. Both of these things slow the //gs down, and also quallify it as Mac-like. However, it does NOT qualify it as 68000-like. Sorry. > [ 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. Before I get any flames about games and their usefullness, etc. I should point out that I primarily program games, so that is the primary focus of my arguments. If it's not a game, it's going to use graphics (if I write it that is.) So the toolbox routines are out, in my book. >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. > >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. The end-user isn't going to have a way (usually) to modify the toolbox routine that had the problem. And I also would appriciate an explination of exactly what it is you're trying to say here. >You are perfectly free to bypass the toolbox. > >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 also a lot more specific. Toolbox routines are generalized a great deal. 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. >--David A. Lyons a.k.a. DAL Systems > PO Box 287 | North Liberty, IA 52317 > BITNET: AWCTTYPA@UIAMVS > CompuServe: 72177,3233 > GEnie mail: D.LYONS2 Tom Schenck, Member 52nd St Development Team -- UUCP: {cbosgd, hplabs!hp-sdd, sdcsvax, nosc}!crash!pnet01!maddie ARPA: crash!pnet01!maddie@nosc.mil INET: maddie@pnet01.CTS.COM Disclaimer : The only company who's thoughts are my own is owned by me. Tom Schenck, member 52nd Street Development Team.
gandreas@umn-d-ub.D.UMN.EDU (Glenn Andreas) (08/02/88)
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 | = =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=