Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!rutgers!ucsd!ucbvax!UIAMVS.BITNET!AWCTTYPA
From: AWCTTYPA@UIAMVS.BITNET ("David A. Lyons")
Newsgroups: comp.sys.apple
Subject: GS/Mac toolbox "interpreting"
Message-ID: <8807302312.aa12461@SMOKE.BRL.ARPA>
Date: 31 Jul 88 22:06:31 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 69
X-Unparsable-Date: Saturday 30 Jul 88 5:34 PM CT

>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