Path: utzoo!attcan!utgpu!news-server.csri.toronto.edu!rutgers!usc!samsung!crackers!cpoint!frog!rmk
From: rmk@frog.UUCP (Rick Kelly)
Newsgroups: comp.arch
Subject: Re: TI 99/4 speed (was Re: Register Allocation and Aliasing)
Message-ID: <17275@frog.UUCP>
Date: 1 Aug 90 05:38:00 GMT
References: <1990Jul24.234511.10564@esegue.segue.boston.ma.us> <12300@encore.Encore.COM> <9408@goofy.Apple.COM>
Reply-To: rmk@frog.UUCP (PUT YOUR NAME HERE)
Distribution: usa
Organization: Charles River Data Systems
Lines: 28

In article <9408@goofy.Apple.COM> esmith@apple.com (Eric Smith) writes:
>From article <1990Jul24.234511.10564@esegue.segue.boston.ma.us>, by 
>msnyder@cis.ohio-state.edu (Michael V Snyder):
>> Ah yes.  The TI 99/4 was slow only in BASIC, and that was because its
>> basic interpreter was written not in assembler, not in some high level
>> compiled language, but in ANOTHER INTERPRETED LANGUAGE!  There was,
>I don't know what language was used to implement TI 99/4 BASIC, although
>I would bet that it was in assembler.
>The amazing slowness (could they have made it slower if they tried?) was
>due to BASIC storing the user's program and variables in the memory
>attached to the TMS9918 VDP (video data processor).  Every time the
>interpreter needed to access a byte of the BASIC program or variable, it
>had to write the address to the VDP then read the data.

	The TI 99/4 BASIC interpreter was written in GPL (Graphics Programming
Language), which was in turn interpreted by a GPL interpreter in the TI roms.
Every BASIC instruction was interpreted twice!  The actual speed of BASIC
programs was remarkable considering this handicap.

	I spent many hours with this machine trying to write tighter, faster
code.  Construction of loops and the placement of "gosub" routines had to
be done with care.

	The Extended BASIC cartridge seemed to have some routines written in
native code, and there was a noticeable peerformance difference.


Rick Kelly	Charles River Data Systems	508-626-1011	rmk@frog.UUCP