Why twice interpreted TI BASIC?

[RXB]

Something everyone has seen on the TI99/4A over the years is that PAUSE while VDP memory is being GARBAGE COLLECTED.

It does this mostly when you use ONLY VDP as you run out of space much more often with only 12K available vs 24K of RAM that DOES NOT HAVE ANY NEED FOR THIS!

Anyone using TI Basic will see this happen more often then with a 32K installed for the simple reason that it has to be called more often then XB would need to do it.

 

I do not need to provide an example when anyone that ever used a TI has seen it on the Console alone way to often.

Much less on XB with 32K installed as unless you are using tons of strings it is unlikely in XB you could force it to do this so often as Basic constantly does it.

After all you are restricted to 12K VDP in Basic unlike XB that had 32K more available to use.

 

I should add that XB has a ROM Garbage Collection that is better then the one in Console ROM entirely written in Assembly unlike Console ROM/GROM.

[senior_falcon]

What you posted was: "Run a large program and the larger it becomes the worse Basic will perform, unlike XB that runs a small program same as large."

This statement makes it sound like the execution speed of the instructions slows down as the program gets larger. If you are talking about the garbage collection, then yes, that definitely will happen more frequently using BASIC and as you mention, it is slower in BASIC.

[RXB]

1 hour ago, senior_falcon said:

What you posted was: "Run a large program and the larger it becomes the worse Basic will perform, unlike XB that runs a small program same as large."

This statement makes it sound like the execution speed of the instructions slows down as the program gets larger. If you are talking about the garbage collection, then yes, that definitely will happen more frequently using BASIC and as you mention, it is slower in BASIC.

So good you agree Basic is slower the larger the program as then more often you get Garbage Collection routine running, thus slowing Basic.

Now mind you remember XB if running tons of strings this effect slows XB, but same program in Basic will be almost crippled in comparison.

This is especially clear if running over 11K programs in Basic vs XB with 32K installed.

[+OLD CS1]

2 hours ago, Tursi said:

Unfortunately, those also exist when accessing VDP.

I keep forgetting about that because it does not make any damn sense.  Look at the Amiga, as an example, and you will find 8-bit peripherals on the 16-bit buss with no such encumbrance.  Admittedly, I am not an engineer and I have never designed a full computer system, but I did stay at a Holiday Inn Express last night.

[Airshack]

On 6/21/2021 at 9:55 AM, sometimes99er said:

TI Basic > GPL > Machine-code (Assembler)

https://www.unige.ch/medecine/nouspikel/ti99/gpl.htm
 

So…getting back to my original thread question…
 

   TI BASIC is FIRST-interpreted by the 99/4’s BASIC interpreter into GPL because the original designers did not know which CPU was going into the machine, or had another (failed) CPU in mind, or just planned to program in GPL, so they slapped BASIC atop GPL. 
 

   Next, the resulting GPL code is SECOND-interpreted (by the GPL interpreter) into TMS9900 machine code in order to run on the 99/4A’s actual CPU.

 

   Safe to assume all other machines of the era began their life with a specific CPU in mind?

 

   Therefor, the other machines of the era have BASIC interpreters in ROM which transform BASIC code directly to the respective CPU’s machine code — simpler.

 

   One step vs two because the design started with another CPU in mind on the 99/4A?

[+OLD CS1]

4 hours ago, Stuart said:

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

 

[Stuart]

1 hour ago, Airshack said:

So…getting back to my original thread question…
 

   TI BASIC is FIRST-interpreted by the 99/4’s BASIC interpreter into GPL because the original designers did not know which CPU was going into the machine, or had another (failed) CPU in mind, or just planned to program in GPL, so they slapped BASIC atop GPL. 
 

   Next, the resulting GPL code is SECOND-interpreted (by the GPL interpreter) into TMS9900 machine code in order to run on the 99/4A’s actual CPU.

 

   Safe to assume all other machines of the era began their life with a specific CPU in mind?

 

   Therefor, the other machines of the era have BASIC interpreters in ROM which transform BASIC code directly to the respective CPU’s machine code — simpler.

 

   One step vs two because the design started with another CPU in mind on the 99/4A?

Not quite right I think. The intended CPU was (allegedly) the TMS9985 which was still in development, but that was ridden with bugs so they implemented the TMS9900 + support logic to emulate it. I would think GPL was always intended - the GROMs are an efficient (for the time) way to provide lots of memory, plus as TI had patented it they had control of who could develop for the machine. There has been talk of a CPU that could execute GPL directly but I don't think anyone has ever found details about it.

 

[The two block diagrams in the first message of the following thread shows the machine with the intended TMS9985 then modified for the TMS9900]

 

Edited June 22, 2021 by Stuart

[RXB]

2 hours ago, Airshack said:

So…getting back to my original thread question…
 

   TI BASIC is FIRST-interpreted by the 99/4’s BASIC interpreter into GPL because the original designers did not know which CPU was going into the machine, or had another (failed) CPU in mind, or just planned to program in GPL, so they slapped BASIC atop GPL. 
 

   Next, the resulting GPL code is SECOND-interpreted (by the GPL interpreter) into TMS9900 machine code in order to run on the 99/4A’s actual CPU.

 

   Safe to assume all other machines of the era began their life with a specific CPU in mind?

 

   Therefor, the other machines of the era have BASIC interpreters in ROM which transform BASIC code directly to the respective CPU’s machine code — simpler.

 

   One step vs two because the design started with another CPU in mind on the 99/4A?

LOL no TI BASIC is not converted into GPL as GPL is already on the machine built into the console, it was GPL that fired up the Title Screen.

TI Basic is WRITTEN IN GPL already it is NOT INTERPETED and is no different then XB on that level as BOTH ARE WRITTEN IN GPL!

THIS IS NO DIFFERENCE THEN XB AS XB CODE AND TI BASIC CODE ARE ALMOST EXACLTY THE SAME CODE WHY THEY RUN IN EITHER!

Matter of fact most carts are written in GPL!!!!!

 

Saying TI Basic is DOUBLE INTERPETED means you need to explain to me as a GPL programmer  HOW?

[Casey]

Ask yourself a couple of questions.

 

What code does the CPU run?

How does a TI BASIC command end up being something the CPU can execute?

 

Now, ask yourself the same questions for a Commodore PET.

 

What code does the CPU run?

How does a Commodore BASIC command end up being something the CPU can execute?

 

The answers to these questions will explain how people get to the conclusion they do about TI BASIC.

[+OLD CS1]

1 hour ago, RXB said:

Saying TI Basic is DOUBLE INTERPETED means you need to explain to me as a GPL programmer  HOW?

I think this comes from the idea that TI BASIC, as an interpreted language, has many of its internals in GPL, which is not itself a machine-executable language but is executed within the GPL interpreter.  Thus, it is seen as "doubly interpreted."

[Airshack]

2 hours ago, RXB said:

Saying TI Basic is DOUBLE INTERPETED means you need to explain to me as a GPL programmer  HOW?

   Hey Rich  So glad you’re participating in the conversation as you’re possibly the most knowledgeable GPL programmer I’ve ever met. Thank you for always lending an ear. 
 

   I’m not saying anything on this thread other than, “What up with this twice-interpreted reference…yo?”

 

   Somehow my BASIC code (of any variant found on the TI) ends up running on the CPU as machine native code. 
 

   What I’m asking for here is a very high-level explanation of that process. 

 

   One great part about asking a question on this forum is you end up learning many things. 

 

   

[Airshack]

1 hour ago, Casey said:

How does a TI BASIC command end up being something the CPU can execute?

^^^^^ what he said.

[jrhodes]

12 minutes ago, Airshack said:

^^^^^ what he said.

As i understand it, it works like this:

TI Basic(or XB) statements >> gpl opcodes >> machine code (literal stream of 1's and 0's)

Even if you code directly in gpl, it still gets turned into machine code at execution.

[RXB]

5 hours ago, Casey said:

Ask yourself a couple of questions.

 

What code does the CPU run?

How does a TI BASIC command end up being something the CPU can execute?

 

Now, ask yourself the same questions for a Commodore PET.

 

What code does the CPU run?

How does a Commodore BASIC command end up being something the CPU can execute?

 

The answers to these questions will explain how people get to the conclusion they do about TI BASIC.

Actually it just means they do not know anything about the TI 99/4A and proof is the things they say that are just wrong.

[RXB]

4 hours ago, OLD CS1 said:

I think this comes from the idea that TI BASIC, as an interpreted language, has many of its internals in GPL, which is not itself a machine-executable language but is executed within the GPL interpreter.  Thus, it is seen as "doubly interpreted."

Sorry that is incorrect, now you could say XB and TI Basic are doubly interpreted as:

First layer is Basic or XB tokened code

Second layer is GPL tokened code 

Third layer is Assembly

 

But the same applies to Forth not compiled too:

First layer is Forth Tokened code

Second layer is Assembly

 

So Forth and GPL both non compiled are the same, but GPL is run from GROM which is another can of worms. GROMs are a hard ware restriction.

Honestly if GPL ran from RAM or ROM just like Forth they would be around the same speed.

[+OLD CS1]

4 minutes ago, RXB said:

Sorry that is incorrect, now you could say XB and TI Basic are doubly interpreted as:

First layer is Basic or XB tokened code

Second layer is GPL tokened code 

Third layer is Assembly

I appreciate pedantry.

[+TheBF]

1. First layer is Basic or XB tokened code
2. Second layer is GPL tokened code 
3. Third layer is Assembly

 

1. First layer is Forth Tokened code
2. Second layer is Assembly

 

2 layers to native code vs 1 layer to native code.

Ergo "double interpreted" because GPL is not native code. Its not a crime, just a computer system.

 

If we want to be pedantic because @OLD CS1 appreciates it   "Assembly" is not native code either.  It's a representation.

These days I am reading that different assemblers can generate different binary images for the same source code.

The world has gone crazy.  

 

 

[+mizapf]

19 minutes ago, TheBF said:

1. First layer is Basic or XB tokened code
2. Second layer is GPL tokened code 
3. Third layer is Assembly

I find this list misleading to some extent. It suggests (to the inexperienced reader) that the BASIC programs (tokens) are translated to GPL, which is not the case. Hence, I usually disagree with a description like "double interpretation".

[+TheBF]

4 minutes ago, mizapf said:

I find this list misleading to some extent. It suggests (to the inexperienced reader) that the BASIC programs (tokens) are translated to GPL, which is not the case. Hence, I usually disagree with a description like "double interpretation".

I guess that could happen with someone who is not familiar with how VMs work.

Is it correct to say that the TI BASIC interpreter is written in GPL?

[Count9929A]

26 minutes ago, TheBF said:

I guess that could happen with someone who is not familiar with how VMs work.

Is it correct to say that the TI BASIC interpreter is written in GPL?

Let me give my impression, not knowing anything about GPL or BASIC internals, but knowing something about computer science in general. For me, "interpreter" is a program (written in language A) that reads tokens of a language B and executes them, i.e. modifies the state of the memory according to the intended semantics of language B. From what I read in this thread (and others) I think that this is what happens with TI BASIC, which is executed by an interpreter, written in GPL. 

To me, "BASIC is interpreted by GPL" would not mean that BASIC tokens are translated to GPL tokens. I would have called this hypothetical process "BASIC is compiled into GPL".

 

Therefore if (as I think to have understood here in the forum) GPL instructions are themselves executed by a TMS9900 interpreter, (in the same sense as BASIC is interpreted in GPL) for me to say that BASIC is "doubly interpreted" makes sense: it is obviously a quick (and possibly inaccurate) way of describing the above process

[+mizapf]

I don't want to enforce a particular interpretation, actually. ? My only concern is that people who know a bit less than we do may be either puzzled, amused, or confirmed in their view about the weird architecture when they hear about "double interpretation", without being aware of the different levels of abstraction. I find it difficult to drop my existing knowledge to be able to estimate that (in German we have the word "sich hineindenken", "to think into someone").

 

And we all know enough examples of strange interpretations, up to the level of falseness.

[senior_falcon]

48 minutes ago, Count9929A said:

Let me give my impression, not knowing anything about GPL or BASIC internals, but knowing something about computer science in general. For me, "interpreter" is a program (written in language A) that reads tokens of a language B and executes them, i.e. modifies the state of the memory according to the intended semantics of language B. From what I read in this thread (and others) I think that this is what happens with TI BASIC, which is executed by an interpreter, written in GPL. 

To me, "BASIC is interpreted by GPL" would not mean that BASIC tokens are translated to GPL tokens. I would have called this hypothetical process "BASIC is compiled into GPL".

 

Therefore if (as I think to have understood here in the forum) GPL instructions are themselves executed by a TMS9900 interpreter, (in the same sense as BASIC is interpreted in GPL) for me to say that BASIC is "doubly interpreted" makes sense: it is obviously a quick (and possibly inaccurate) way of describing the above process

This is exactly how I understand it. In Heiner Martin's book TI INTERN, on page 9 is written:

"The ROM contains the GPL Interpreter, the interrupt routines, the Cassette routines, part of the Basic Interpreter and several Utility Subroutines."

and later on that page:

"The GPL Interpreter is located at addresses >0024 through >08FF and in some other small areas. There is little difference between the GPL Interpreter and the Basic Interpreter, ....."

In this book are many more references to both the GPL Interpreter and the BASIC Interpreter.

 

When you enter a BASIC/XB program, what you type is converted into tokens. You can see these using the Classic99 debugger. These are not executable code. There must be a BASIC/XB interpreter that knows what to do with them. That interpreter is written in GPL (with some assembly support). When you write a program in GPL, a GPL assembler is used to convert the readable GPL program into numbers. You could either call these GPL tokens or GPL instructions, but the point is that you need a second layer of code beyond the BASIC interpreter that knows what to do with GPL tokens/code. You can call this second layer of code the GPL interpreter, or if you prefer you could call it the GPL emulator. To me it is a distinction without a difference.

 

By itself, GPL is a fine language and programs written in it can run at a decent speed. TI's mistake was in writing the BASIC/XB interpreter in GPL.  This leads to performance that is very sub par, especially when compared to other computers of that era.

 

[HOME AUTOMATION]

On 6/22/2021 at 12:22 PM, RXB said:

Something everyone has seen on the TI99/4A over the years is that PAUSE while VDP memory is being GARBAGE COLLECTED.

It does this mostly when you use ONLY VDP as you run out of space much more often with only 12K available vs 24K of RAM that DOES NOT HAVE ANY NEED FOR THIS!

Hmm, I'm not sure that everyone is aware of that... My first three consoles had this GARBAGE COLLECTION bug, and yes it happens more frequently as free space diminishes.

 

I had a program monitoring key presses, that would display two lists of strings, and their associated states. The display was updated using PRINT commands. When refreshing the entire display, the lockup(abo. 2 sec.) would occur three or four times. These delays also interfered with the key scanning routine. The time-clock update-signal came at one minute intervals, and was wired to the space bar(as the higher priority overrides other depressed keys). In order not to miss a clock signal I had to use a delay-circuit to hold the signal active for 2 1/2 seconds.

 

By '94 all of those TI's, had been removed from my possession! It was a few years before I started replacing equipment. The next four TI's did NOT have the GARBAGE COLLECTION bug, the EMU's don't either. I don't have a BIN of the buggy GROM, so I can't even reproduce the lock-up conditions. However, it was crippling, and part of the reason that I moved all programing over to assembly.

 

      P.S. I remember wishing that TI would perhaps fix this apparent anomaly in the '80s, to no avail.

            In hindsight, they already had. But unfortunately, I was unaware/not effected.

[RXB]

12 hours ago, OLD CS1 said:

I appreciate pedantry.

Hmmm what is the name of this post link? "Why twice interpreted TI BASIC?"

[+OLD CS1]

1 minute ago, RXB said:

Hmmm what is the name of this post link? "Why twice interpreted TI BASIC?"

Indeed. Your response with more in-depth, succinct and minor detail, strict in your presentation, was appreciated.