Jump to content
Airshack

Why twice interpreted TI BASIC?

Recommended Posts

I forget the specifics behind exactly why the BASIC on the 99/4 machines needed to be twice interpreted? 
 

 

Share this post


Link to post
Share on other sites

This is what I recently explained; it is not the TI BASIC program that is twice interpreted, but it is once interpreted by the TI BASIC interpreter which itself is written in GPL. It is a matter of definitions whether you understand GPL as an interpreted language or as the machine language of a virtual architecture.

  • Like 2

Share this post


Link to post
Share on other sites
13 minutes ago, mizapf said:

This is what I recently explained; it is not the TI BASIC program that is twice interpreted, but it is once interpreted by the TI BASIC interpreter which itself is written in GPL. It is a matter of definitions whether you understand GPL as an interpreted language or as the machine language of a virtual architecture.

Well in a way it is slower then Extended Basic as when you have Memory Expansion (32K or SAMS) it puts XB programs in RAM not VDP like TI Basic does.

Thus TI Basic only runs from VDP totally including Programs and Variables, Extended Basic also is faster as Numeric Variables are in RAM not VDP.

And in TI Basic Programs, String Variables, Numeric Variables are all stored in slower VDP RAM, vs Extended Basic that only stores String Variables in VDP RAM.

 

This is why when you put a TI Basic Program into XB and run it you can see a speed improvement.

  • Like 2

Share this post


Link to post
Share on other sites

If they had a separate processor for the GPL interpreter that helped too.    

  • Like 2

Share this post


Link to post
Share on other sites

Because nobody knew what the CPU was going to be until very late ;)

 

I don't think we ever saw any explicit documentation explaining the creation of GPL, have we? We've had some interesting dumps recently...

 

  • Like 2
  • Thanks 1

Share this post


Link to post
Share on other sites

My recollection is that adding the 32K RAM expansion to Extended Basic yields only a very slight (~ 2%) increase in execution speed (which was disappointing, once upon a time). Which is to say that running Extended Basic entirely out of VDP doesn't result in a significant speed penalty.

 

Perhaps the 32K expansion-aware code isn't very well optimized? 

 

  • Like 1

Share this post


Link to post
Share on other sites
26 minutes ago, Reciprocating Bill said:

My recollection is that adding the 32K RAM expansion to Extended Basic yields only a very slight (~ 2%) increase in execution speed (which was disappointing, once upon a time). Which is to say that running Extended Basic entirely out of VDP doesn't result in a significant speed penalty.

 

Perhaps the 32K expansion-aware code isn't very well optimized? 

 

It entirely depends on the programs loaded and running there are some programs that are extremely slow in XB or in TI Basic.

If you have a program intensively running and making strings it will run significantly slower in TI Basic.

As the entire program has to make and modify strings and run program from VDP so much more access to VDP is required vs XB that would run the program from RAM.

 

If you want to prove this try this:

TI Basic

100 FOR X=1 TO 1E3

110 X$="THIS IS A TEST #"&STR$(X)

120 NEXT X

 

XB 

100 FOR X=1 TO 1E3 :: X$="THIS IS A TEST #"&STR$(X) :: NEXT X

 

Just time each till and see how huge the difference it as a result.

  • Like 2

Share this post


Link to post
Share on other sites

No benefit to being 16 bit because of using 8bit motherboard?  It's double processed too?  Faster or slower than a C64?

Share this post


Link to post
Share on other sites
14 minutes ago, SkyPilot said:

No benefit to being 16 bit because of using 8bit motherboard?  It's double processed too?  Faster or slower than a C64?

It can do some things faster but not everything. For example it has a divide instruction in the CPU so that is faster. The 9900 CPU consumes a lot of clock cycles to what it does but it also has a more powerful instruction set than the 6502 so it can do more with fewer instructions many times.  TI-99 was designed in 1977/78 so C64 had a couple of years more "progress" too draw from which was pretty significant in those days.

 

There is a small patch of memory (256 bytes) :) running on the 16bit buss and most programs do a lot of fancy business to optimize the use of that RAM space for important stuff. 

 

Double processed?  If you mean BASIC running on a virtual machine then yes, but that is only BASIC for the most part. 

You can program in GPL which is the native language of the virtual machine.

People are also programming in C, Pascal, Fortran, Forth and Assembler as well and there is a remarkable BASIC compiler now that is a game changer.


 

  • Like 1

Share this post


Link to post
Share on other sites
33 minutes ago, RXB said:

XB 

100 FOR X=1 TO 1E3 :: X$="THIS IS A TEST #"&STR$(X) :: NEXT X

 

Just time each till and see how huge the difference it as a result.

In-line with @Reciprocating Bill's question -- XB with and without 32k -- I compared apples to apples:

 

XB with 32k: ~39 seconds

XB w/o 32k: ~41 seconds

  • Like 1

Share this post


Link to post
Share on other sites
45 minutes ago, OLD CS1 said:

In-line with @Reciprocating Bill's question -- XB with and without 32k -- I compared apples to apples:

 

XB with 32k: ~39 seconds

XB w/o 32k: ~41 seconds

And you omitted TI Basic results?

 

Share this post


Link to post
Share on other sites

Rich, you are always blaming VDP access for the slowness of TI BASIC, but it just ain't so. It is true that VDP access is not exactly a performance enhancer, and there is no question your  program in post #5 is way slower in TI BASIC. But VDP access has little to do with the slowness, as shown by OLD CS1's test showing that XB running totally from VDP ram is just slightly slower than the same program running from 32K.

 

From your post #4:

This is why when you put a TI Basic Program into XB and run it you can see a speed improvement.

Again, the reason for the speed improvement has little to do with VDP ram access. The real cause of the slowness is  because more of TI BASIC is written in GPL, while more of XB is written using assembly.

Try this program running in TI BASIC (running in VDP ram) and in XB with 32K (running in CPU ram)

10 FOR I=1 TO 1000
20 X=I*I
30 NEXT I

According to you, the VDP access will slow the BASIC program to a crawl, but actually it is slightly faster.

 

  • Like 1

Share this post


Link to post
Share on other sites

I had some old tests in the can that I cleaned up here.

They are just writing a string to VDP RAM and CPU RAM. 

I wrote equivalent code that is already in Forth in a way to operate on VDP RAM.

I wanted to see if there was a big hit if piled text into VDP RAM.

As you can see the speed is not much different. 

 

EDIT: And when I take care to use the same length of string, VDP RAM is faster. 

 

Spoiler
\ cpu ram vs vdp ram tests

NEEDS .S      FROM DSK1.TOOLS
NEEDS ELAPSE  FROM DSK1.ELAPSE
NEEDS VHERE   FROM DSK1.VDPMEM

MARKER /VDP

DECIMAL
: VBUFFER: ( n -- Vaddr) VHERE CONSTANT    VALLOT ;
: BUFFER:  ( n -- addr)  CREATE ALLOT ;  ( CPU ram buffer creator)

\ VDP printing
: VTYPE    ( Vaddr len -- ) 0 ?DO  VCOUNT EMIT LOOP DROP ;
: VPRINT   ( V$ -- )CR VCOUNT VTYPE ; ( print VDP string )

\ Equivalent CPU print
: PRINT    ( $ -- ) CR COUNT TYPE ;  ( print a CPU string)

DECIMAL
50 VBUFFER: V$
50  BUFFER: C$

( String tests ...)
: VDP$TEST   ( -- )
         CR ." ======================== "
         CR ." Testing VDP string Write"
         CR
         S" Write this string to VDP RAM 3000 times." V$ VPLACE
         V$ VPRINT
         TICKER OFF
         3000 0
         DO
              S" Write this string to VDP RAM 3000 times." V$ VPLACE
         LOOP
         CR ." VDP string test ends"
         CR .ELAPSED ;

: CPU$TEST   ( -- )
         CR ." ======================== "
         CR ." Testing CPU string Write."
         CR
         S" Write this string to CPU RAM 3000 times" C$ PLACE
         CR C$ PRINT
         TICKER OFF
         3000 0 
         DO
            S" Write this string to CPU RAM 3000 times." C$ PLACE
         LOOP
         CR
         CR ." CPU string test ends"
         .ELAPSED ;

 

 

 

  • Like 2

Share this post


Link to post
Share on other sites
2 hours ago, SkyPilot said:

No benefit to being 16 bit because of using 8bit motherboard?  It's double processed too?  Faster or slower than a C64?

In my testing, assembly code is about equivalent to contemporary Z80s, didn't test against 6502s.

 

  • Like 2

Share this post


Link to post
Share on other sites
3 minutes ago, Tursi said:

In my testing, assembly code is about equivalent to contemporary Z80s, didn't test against 6502s.

From the infamous 2nd BYTE Sieve article (BYTE Magazine 1/83): 

 

The fastest Z80 timing on the BYTE Sieve was 6.8 seconds (assembly). The clock isn't stated. The fastest 6502 version was 13.9 seconds (assembly). OSI Superboard (clock not stated).

 

I get 6.3 seconds on my TI in assembly - but that's with 16-bit RAM installed. Stock console, a bit over 7 seconds with registers AND code in scratchpad (how often can you do that?), about 10 seconds with registers in scratchpad and code in standard RAM (the most common configuration). 15 seconds when everything, including registers, is in 8-bit RAM. Fine for non-performance sensitive code. 

 

Freeing the CPU with 16-bit RAM seals the deal. But then SAMS is ruled out. Gotta choose. 

 

https://archive.org/details/byte-magazine-1983-01-rescan/mode/2up

  • Like 2

Share this post


Link to post
Share on other sites
2 hours ago, RXB said:

And you omitted TI Basic results?

Yes.

4 hours ago, Reciprocating Bill said:

My recollection is that adding the 32K RAM expansion to Extended Basic yields only a very slight (~ 2%) increase in execution speed (which was disappointing, once upon a time). Which is to say that running Extended Basic entirely out of VDP doesn't result in a significant speed penalty.

 

Perhaps the 32K expansion-aware code isn't very well optimized?

 

Share this post


Link to post
Share on other sites
35 minutes ago, Reciprocating Bill said:

Freeing the CPU with 16-bit RAM seals the deal. But then SAMS is ruled out. Gotta choose.

Given these results, I would figure 8-bit RAM and associated wait-states eliminate any advantage the system would have by not running in VDP RAM.

Share this post


Link to post
Share on other sites
3 hours ago, senior_falcon said:

Rich, you are always blaming VDP access for the slowness of TI BASIC, but it just ain't so. It is true that VDP access is not exactly a performance enhancer, and there is no question your  program in post #5 is way slower in TI BASIC. But VDP access has little to do with the slowness, as shown by OLD CS1's test showing that XB running totally from VDP ram is just slightly slower than the same program running from 32K.

 

From your post #4:

This is why when you put a TI Basic Program into XB and run it you can see a speed improvement.

Again, the reason for the speed improvement has little to do with VDP ram access. The real cause of the slowness is  because more of TI BASIC is written in GPL, while more of XB is written using assembly.

Try this program running in TI BASIC (running in VDP ram) and in XB with 32K (running in CPU ram)

10 FOR I=1 TO 1000
20 X=I*I
30 NEXT I

According to you, the VDP access will slow the BASIC program to a crawl, but actually it is slightly faster.

 

You need to understand if you run a XB program exactly like Basic you are just purposely hobbled the reason for XB in the first place.

Example Basic does not have :: to run multiple commands in a program so not using them is purposely rigging the contest for Basic to look better.

The entire reason for one over the other is the advantages but you insist taking them away from one but not the other?

Also XB has floating point math routines built into XB thus why Decimal slows XB down. Basic has 3 times less features as a result.

As stated if you use strings as my first example it is no contest which one is faster between XB and Basic.

 

And I want you to show me what same commands are not written in GPL for XB as for Basic.

Please if you know something I do not show it to me? (I seem to have a pretty good grasp of GPL in both of these XB and Basic)

 

And I am working on making XB mostly Assembly using the additional ROMs in FinalGROM.

I think the biggest pain in rear in XB is using Floating Point every single time it talks to a number of any kind, integer math would be speed up.

Share this post


Link to post
Share on other sites

Every couple of years this same discussion happens, usually with a few minor variations.

 

"You need to understand if you run a XB program exactly like Basic you are just purposely hobbled the reason for XB in the first place.

Example Basic does not have :: to run multiple commands in a program so not using them is purposely rigging the contest for Basic to look better.

The entire reason for one over the other is the advantages but you insist taking them away from one but not the other?"

 

99.4a percent of the time TI BASIC is slower than XB. Why is this? You stated that VDP access time is the main culprit. Perhaps that is true. Let's devise an experiment to try to find out. Run a program in BASIC where it runs from VDP ram and in XB with 32K where it runs from CPU ram and compare the speeds. Since the purpose of this test is to find out whether VDP access kills performance the way you say, we must run the same program in both BASICs, without giving an advantage to either. Surprisingly, it turns out that BASIC has a slight performance edge, showing that VDP access time is not a major problem.

 

"Also XB has floating point math routines built into XB thus why Decimal slows XB down. Basic has 3 times less features as a result."

 

This statement makes no sense. BASIC also uses floating point math routines. Plus, I would hazard the guess that BASIC has fewer features because is has 36K less "preprogrammed memory".

 

"As stated if you use strings as my first example it is no contest which one is faster between XB and Basic."

 

Your first example is definitely slower when run in TI BASIC. Since both BASIC and XB keep strings in VDP ram, how can this difference could be caused by VDP access time as you maintain.

 

"And I want you to show me what same commands are not written in GPL for XB as for Basic.

Please if you know something I do not show it to me? (I seem to have a pretty good grasp of GPL in both of these XB and Basic)"

 

It is a fact that many commands are markedly faster in XB, even when running XB totally in VDP ram. It seems to me there are only two possible reasons:

1 - The programmers at TI got a lot smarter about using GPL and learned how to program it much more efficiently, or:

2 - Some of the GPL programming was replaced with assembly routines.

Which of these seems most likely to you?

 

"And I am working on making XB mostly Assembly using the additional ROMs in FinalGROM."

 

Actions speak louder than words. You won't come out and admit that GPL is the major bottleneck, but if you really believed that VDP access time was a biggest problem you wouldn't be wasting your time with assembly. Instead you would work on moving all string access so it happened in SAMs or similar CPU memory.

 

"I think the biggest pain in rear in XB is using Floating Point every single time it talks to a number of any kind, integer math would be speed up."

 

This is tricky but it would be cool if you can do it.

  • Like 4

Share this post


Link to post
Share on other sites

I never once said Basic changed the VDP Access time is the difference between Basic and XB.

My point is EVERTHING RUNS FROM VDP IN BASIC, NOTHING IN RAM....NOTHING.

If everything runs from VDP ONLY then twice as many commands have VDP access delay, then if you run many less VDP access commands, simple logic applies here!

Both have exactly Fast RAM of the same amount, VDP the same amount, but XB has use of RAM that programs and Numeric Variables reside within.

Run a large program and the larger it becomes the worse Basic will perform, unlike XB that runs a small program same as large. (Prescan is longer)

Console only most commands are the same in GPL, but XB does have some Assembly like MVDN or MVUP that specifically used for moving VDP to VDP

or VDP to RAM or RAM to VDP that Basic does not have. For example the PRINT command in Basic has way less code then XB does but XB does well anyway.

RND in XB was so bad at being slow and way to complicated I had to replace it in RXB.

GPL has a hardware issue as Tursi has pointed out previously, the bottle neck is hardware GROMs not the language GPL.

Fix the hardware issue and as Tursi said it would be as fast as Forth, this would make Basic much more viable as a useful language.

 

This reminds me of that old saying "Don't kick the cat when you are mad at the dog!"

Share this post


Link to post
Share on other sites
47 minutes ago, RXB said:

 

Fix the hardware issue and as Tursi said it would be as fast as Forth...

Minor point, but it would be as fast as a byte-code Forth. (which is kind of what it is, with no text interpreter, since it has 2 stacks)

 

It would not be as fast as an indirect address threaded Forth, or a direct address threaded Forth, or a sub-routine threaded Forth, or a native code Forth. 

:)  Sorry uber Forth nerd stuff.

  • Like 4

Share this post


Link to post
Share on other sites

I never once said Basic changed the VDP Access time is the difference between Basic and XB.

My point is EVERTHING RUNS FROM VDP IN BASIC, NOTHING IN RAM....NOTHING.

If everything runs from VDP ONLY then twice as many commands have VDP access delay, then if you run many less VDP access commands, simple logic applies here!

 

Question: When you are running a program in XB without 32K or in TI BASIC, would you agree that both programs are running completely from VDP memory? (Hint - the correct answer is Yes)

When you run your program in post #8 in both XB (sans 32K) and TI BASIC you will see that BASIC is much slower than XB. Since both are running completely within VDP ram, it logically follows that something else is making XB run so much faster.

 

 

Both have exactly Fast RAM of the same amount, VDP the same amount, but XB has use of RAM that programs and Numeric Variables reside within.

Run a large program and the larger it becomes the worse Basic will perform, unlike XB that runs a small program same as large. (Prescan is longer)

Please post an example of a large program that performs as you describe.

Console only most commands are the same in GPL, but XB does have some Assembly like MVDN or MVUP that specifically used for moving VDP to VDP

or VDP to RAM or RAM to VDP that Basic does not have. For example the PRINT command in Basic has way less code then XB does but XB does well anyway.

RND in XB was so bad at being slow and way to complicated I had to replace it in RXB.

GPL has a hardware issue as Tursi has pointed out previously, the bottle neck is hardware GROMs not the language GPL.

Fix the hardware issue and as Tursi said it would be as fast as Forth, this would make Basic much more viable as a useful language.

Translation: If GPL were faster then it wouldn't be so slow.

  • Like 2

Share this post


Link to post
Share on other sites
Posted (edited)
13 hours ago, OLD CS1 said:

Given these results, I would figure 8-bit RAM and associated wait-states eliminate any advantage the system would have by not running in VDP RAM.

Unfortunately, those also exist when accessing VDP. ;)

 

VDP access time is the same as any other 8 bit memory in the system - the only slowdown comes from needing to change the address (which GPL does all the time, even when it doesn't need to).

 

edit: I broke the quote below, and the editor won't let me fix it, but my part starts with "The GROMs are slow memory" ;)

RXB said:

GPL has a hardware issue as Tursi has pointed out previously, the bottle neck is hardware GROMs not the language GPL.

Fix the hardware issue and as Tursi said it would be as fast as Forth, this would make Basic much more viable as a useful language.

 

 

The GROMs are slow memory, but my stance is that GPL itself could be improved. I've shown that GROMs are accessed so infrequently when executing GPL that speeding them up makes no noticeable difference - I did this test with the UberGROM. When replacing all GROMs with the UberGROM and running it at (roughly) 12 times faster than a real GROM (measured via logic analyzer), the difference in execution speed in TI BASIC was not humanly perceivable. I studied the interpreter code to see why and determined that on average (IIRC) it executes 30 or more CPU instructions for every read from GROM. If we assume a GROM access costs three times the average CPU instruction then this would mean that even if GROM access was free (which isn't possible, the MOV opcode still takes time) the interpreter would only be about 10% faster. The worst offender is the MOVE opcode, which is used a lot - it does a lot of tests and resets VDP or GROM address for every byte moved - dedicated loops or a small buffer would speed it up a lot.

 

I maintain that the GPL interpreter could be written to be far more performant, though it would probably take more ROM space to do it. We know a lot more about the machine than was known when it was written. Every so often I sit down to prove it, but oi, that's a big task. ;)

 

Edited by Tursi
  • Like 2

Share this post


Link to post
Share on other sites

I think we need to start a thread "Questions you're not allowed to ask".  ;-)

  • Like 3
  • Haha 2

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...