Jump to content
IGNORED

That's why TI BASIC is so slow!


Airshack

Recommended Posts

Speaking of which, is there a simple calculator program for the TI? I don't recall if there ever was, but one would be nice in FlashROM format.

 

 

Simple calculator? How about a BASIC one? Option 1 from the boot menu :):

 

TI BASIC Calculator

 

Edited by chue
  • Like 2
Link to comment
Share on other sites

 

I'm not sure the comparison to C is appropriate.

C is not an interpreter so comparing speed of GPL code to compiled C code... even if GPL uses 16 bit CPU RAM, the C code wins hands down.

If you compare a native assembly BASIC interpreter to running one on GPL, the native one wins hands down.

If you write a BASIC interpreter in C with some assembly subroutines, that probably wins hands down as well. It probably won't be as fast as the one completely written in assembly though.

 

People keep calling GPL an interpreter. It is but perhaps it isn't the most precise description.

GPL is a virtual processor/machine, so comparing it to native code or a language compiled to native code really isn't a fair comparison.

 

The problem is that running an interpreter on top of GPL is slower than a native 9900 BASIC interpreter would be even if the native code interpreter had the same restrictions (using VDP RAM). And running any interpreter out of VDP RAM is slower than if they used CPU RAM.

Hmm GPL is not INTERPRETED it is compiled the same as Assembly or C.

 

I use a COMPILER TO CREATE GPL IT IS NOT INTERPRETED!

 

You are thinking XB or BASIC!

Link to comment
Share on other sites

A native BASIC interpreter that uses CPU RAM, with at least 4K of 16 bit RAM, is going to be a big improvement speed wise.

I would be surprised if Ahl's Benchmark took over 3 minutes, and I would not be surprised if it took just over 2 minutes. Beyond that, I have nothing to go on.
It is going to add $50-$100 to the original price. The scratchpad RAM goes away, and maybe some ROM so there may be some offset to the cost but it's impossible to say how much.
By the price war you are talking $25? The MC-10 had 4K of SRAM and the entire machine probably cost under $50 to make in 1983, so... ????

I know 4K sounds pretty anemic... but remember, a 4K TI would be able to use all graphics RAM how it sees fit.
Machine language programs could use unused video RAM for storage, or all of it could be for graphics.
If TI adds even simple bitmapped graphics support (SET, RESET, CLS... ), you can easily make hi-res 3D plots, pretty pictures, etc...
And it's enough to hold speed critical code/data and put everything else in external 8 bit RAM.

Even clever BASIC programmers could put speed critical subroutines in 16 bit RAM.

Link to comment
Share on other sites

Hmm GPL is not INTERPRETED it is compiled the same as Assembly or C.

 

I use a COMPILER TO CREATE GPL IT IS NOT INTERPRETED!

 

You are thinking XB or BASIC!

Does the CPU directly run GPL?

*edit*

Wrong question.

 

Are you compiling to GPL, or are you compiling GPL to 9900 machine code?

Edited by JamesD
Link to comment
Share on other sites

Does the CPU directly run GPL?

*edit*

Wrong question.

 

Are you compiling to GPL, or are you compiling GPL to 9900 machine code?

Yea wrong question the only code the CPU will run is Machine Language for the 9900 CPU.

 

Now the TI99/4A OS is in ROM zero and part of that OS is GROM zero for interface and menus, along with I/0 and Device access.

 

I use the Ryte Data GPL Compiler to create Object Code.

 

It creates Object Code loaded into GRAM by the GPL@LOADER I use in Classic99 or on a Real TI99/4A using a GRAM device.

 

Clearly you have never watched any of my GPL HOW 2 Videos;

 

Link to comment
Share on other sites

Yea wrong question the only code the CPU will run is Machine Language for the 9900 CPU.

 

Now the TI99/4A OS is in ROM zero and part of that OS is GROM zero for interface and menus, along with I/0 and Device access.

 

I use the Ryte Data GPL Compiler to create Object Code.

 

It creates Object Code loaded into GRAM by the GPL@LOADER I use in Classic99 or on a Real TI99/4A using a GRAM device.

 

Clearly you have never watched any of my GPL HOW 2 Videos;

 

...

If GPL is interpreted, it's slower than 9900 assembly.

Even if the Ryte Data GPL Compiler turns GPL into 9900 assembly, it's never going to be faster than regular assembly.

If you compile the GPL to assembly, then I suppose it would be faster than C.

Otherwise, it's going to be slower than assembly and C.

 

FWIW, I watched several of your videos some time back.

While developing GPL may be interesting, I see no point in me doing it.

That looks like torture compared to cross development.

I can write in C which is a much higher level language, and if I have to learn GPL or 9900 assembly, I'll take 9900 assembly.

Link to comment
Share on other sites

Hmm GPL is not INTERPRETED it is compiled the same as Assembly or C.

 

I use a COMPILER TO CREATE GPL IT IS NOT INTERPRETED!

 

You are thinking XB or BASIC!

Rich is half right in the above statement. When he writes programs in GPL he writes GPL source code using a text editor. This code is understandable by humans. (provided you know the language) As an example: MOVE >0008 TO >835C FROM GROM @>0FDF

This is easy to understand - move 8 bytes into ram at >835C from the GROM at >0FDF. The GPL compiler turns this source code into object code - which is basically numbers that the computer can understand. Once compiled, the above line becomes:

>3100 085C 0FDF (This makes little sense to us, but the computer likes it)

After being compiled the object code has to be loaded into a GROM. Once there the GPL interpreter is needed to run it. According to Heiner Martin, the GPL interpreter (written in assembly) is located in the console ROM (fast memory running on the 16 bit data bus) from >0024 to >08FF and in some other small areas. When the GPL interpreter is running, when it comes to the >31 it looks at a jump table starting at >03C6 in cpu memory. Since the number is between >20 and >3F the interpreter knows it is MOVE, and that it should branch to >061E and execute the code there. At >061E the move routine has to figure out more things: what kind of memory are you moving from, what kind of memory are you moving to, and how many bytes to move. When the 8 bytes are moved the interpreter goes on to execute the next gpl instruction.

So GPL code must first be compiled, and once it is compiled and loaded then the GPL interpreter is needed to run it.

 

  • Like 2
Link to comment
Share on other sites

If GPL is interpreted, it's slower than 9900 assembly.

Even if the Ryte Data GPL Compiler turns GPL into 9900 assembly, it's never going to be faster than regular assembly.

If you compile the GPL to assembly, then I suppose it would be faster than C.

Otherwise, it's going to be slower than assembly and C.

 

FWIW, I watched several of your videos some time back.

While developing GPL may be interesting, I see no point in me doing it.

That looks like torture compared to cross development.

I can write in C which is a much higher level language, and if I have to learn GPL or 9900 assembly, I'll take 9900 assembly.

No one EVER CLAIMED EVER THE GPL IS FASTER THEN ASSEMBLY, even Forth and C are not as fast.

And GPL IS NOT INTERPRETED any more then C is interpreted they are both COMPILED!

Senior above is correct in that there is a interpreter but that has to exist to talk to GROM for the GPL not unlike Forth code or C code.

 

What I have said is GPL runs from GROM that has a memory access delay, and if ran from RAM would be as fast as C.

 

Fine if you do not want to learn or write GPL I have no problem with it. But why are you harassing me on this?

Edited by RXB
Link to comment
Share on other sites

Rich is half right in the above statement. When he writes programs in GPL he writes GPL source code using a text editor. This code is understandable by humans. (provided you know the language) As an example: MOVE >0008 TO >835C FROM GROM @>0FDF

This is easy to understand - move 8 bytes into ram at >835C from the GROM at >0FDF. The GPL compiler turns this source code into object code - which is basically numbers that the computer can understand. Once compiled, the above line becomes:

>3100 085C 0FDF (This makes little sense to us, but the computer likes it)

After being compiled the object code has to be loaded into a GROM. Once there the GPL interpreter is needed to run it. According to Heiner Martin, the GPL interpreter (written in assembly) is located in the console ROM (fast memory running on the 16 bit data bus) from >0024 to >08FF and in some other small areas. When the GPL interpreter is running, when it comes to the >31 it looks at a jump table starting at >03C6 in cpu memory. Since the number is between >20 and >3F the interpreter knows it is MOVE, and that it should branch to >061E and execute the code there. At >061E the move routine has to figure out more things: what kind of memory are you moving from, what kind of memory are you moving to, and how many bytes to move. When the 8 bytes are moved the interpreter goes on to execute the next gpl instruction.

So GPL code must first be compiled, and once it is compiled and loaded then the GPL interpreter is needed to run it.

 

 

No one EVER CLAIMED EVER THE GPL IS FASTER THEN ASSEMBLY, even Forth and C are not as fast.

And GPL IS NOT INTERPRETED any more then C is interpreted they are both COMPILED!

 

What I have said is GPL runs from GROM that has a memory access delay, and if ran from RAM would be as fast as C.

 

Fine if you do not want to learn or write GPL I have no problem with it. But why are you harassing me on this?

Because I'm hearing two different stories.

Link to comment
Share on other sites

Tomatos Tomotos. Picking a argument over something you admitted you did not want to use. Mostly to pick a argument as far as I can see.

Remember this?

 

Hmm GPL is not INTERPRETED it is compiled the same as Assembly or C.

 

I use a COMPILER TO CREATE GPL IT IS NOT INTERPRETED!

 

You are thinking XB or BASIC!

It wasn't an attack. I was just trying to clarify your response to me which disagreed with everything else I've read.

 

Link to comment
Share on other sites

  1. GPL is assembled to GPL machine code (as @senior_falcon said), which must be interpreted in the way that @senior_falcon detailed because there is no CPU that can execute it, good intentions by TI notwithstanding. That interpreter exists in TMS9900 machine code and it is about 3 KiB in the Console 16-bit ROM.
  2. High-level Forth is compiled into a list of executable addresses (TMS9900 machine code) executed by the Forth inner (address) interpreter, which walks the list of executable addresses and executes them, It is not a lookup interpreter. This Forth interpreter is only 26 bytes long and runs in 16-bit scratchpad RAM.
  3. C is compiled to TMS9900 machine code. It is not interpreted. Compiled C is the fastest of these three languages.

These three languages are not really comparable.

 

...lee

  • Like 2
Link to comment
Share on other sites

 

  1. GPL is assembled to GPL machine code (as @senior_falcon said), which must be interpreted in the way that @senior_falcon detailed because there is no CPU that can execute it, good intentions by TI notwithstanding. That interpreter exists in TMS9900 machine code and it is about 3 KiB in the Console 16-bit ROM.
  2. High-level Forth is compiled into a list of executable addresses (TMS9900 machine code) executed by the Forth inner (address) interpreter, which walks the list of executable addresses and executes them, It is not a lookup interpreter. This Forth interpreter is only 26 bytes long and runs in 16-bit scratchpad RAM.
  3. C is compiled to TMS9900 machine code. It is not interpreted. Compiled C is the fastest of these three languages.

These three languages are not really comparable.

 

...lee

 

 

Agreed. GPL is very more similar to Java, which is compiled into byte code and executed by a virtual machine.

  • Like 1
Link to comment
Share on other sites

 

  1. GPL is assembled to GPL machine code (as @senior_falcon said), which must be interpreted in the way that @senior_falcon detailed because there is no CPU that can execute it, good intentions by TI notwithstanding. That interpreter exists in TMS9900 machine code and it is about 3 KiB in the Console 16-bit ROM.
  2. High-level Forth is compiled into a list of executable addresses (TMS9900 machine code) executed by the Forth inner (address) interpreter, which walks the list of executable addresses and executes them, It is not a lookup interpreter. This Forth interpreter is only 26 bytes long and runs in 16-bit scratchpad RAM.
  3. C is compiled to TMS9900 machine code. It is not interpreted. Compiled C is the fastest of these three languages.

These three languages are not really comparable.

 

...lee

 

Thank you for the clarification.

That is what I understood GPL to be.

 

If people want a native 9900 assembly BASIC interpreter, a GPL source (disassembly) to 9900 assembly source translator could be written to generate a native interpreter.

Maybe add a peephole optimizer to take care of some common problems automatically.

Then it would be more of a case of hand optimizing rather than writing everything from scratch.

There is a good chance it will be huge and will need a lot of work, but someone might want to give it a try.

  • Like 1
Link to comment
Share on other sites

We've been around the shoehorning of the 16-bit CPU. Here's something on the MIPS (Million Instructions Per Second).

 

http://atariage.com/forums/topic/250055-mips

 

If you look at the MIPS rating from that page, it doesn't match empirical data.

Ahls benchmark is something like 4:50 on the TI and 1:50 for Apple. (those aren't exact but in the ballpark)

That already puts the MIPS rating off, let alone if you account for double interpretation, the VDP RAM use, etc...

But Ahls benchmark spends a lot of time on floating point which is native code, so we shouldn't over estimate either.

 

Link to comment
Share on other sites

It seems to be that Rich and many others see compilation and interpretation as opposite pairs, but this is not true. The opposite pairs are interpretation and native execution. That way, it makes sense to say that GPL source code is first assembled to GPL object code (more similar to assembling than compiling) and then interpreted.

 

In fact, machine code is also interpreted, but one level deeper inside the CPU. The CPU has a collection of microprograms, for instance, for LI, MOV, BLWP, and these microprograms are run when their associated object codes are read.

 

This means it depends on the platform whether we can talk of native execution or interpretation. If we consider the GPL virtual machine as the platform, GPL is natively executed. If the platform is the TMS9900 CPU, GPL is interpreted.

  • Like 1
Link to comment
Share on other sites

This confusion came from misused terminology.
A compiler turns a high level language into a lower level language.
GPL is not a high level language.
An Assembler turns human readable forms of a machine's instructions into the machine readable form.
In this case, the machine is the GPL bytecode interpreter.

Forth, UCSD Pascal, Tiny Pascal, BASIC-09, Java, etc... all use bytecodes that are interpreted.

Even many BASIC compilers use bytecode interpreters. They are included with the runtime package.. .

  • Like 1
Link to comment
Share on other sites

It seems to be that Rich and many others see compilation and interpretation as opposite pairs, but this is not true. The opposite pairs are interpretation and native execution. That way, it makes sense to say that GPL source code is first assembled to GPL object code (more similar to assembling than compiling) and then interpreted.

 

In fact, machine code is also interpreted, but one level deeper inside the CPU. The CPU has a collection of microprograms, for instance, for LI, MOV, BLWP, and these microprograms are run when their associated object codes are read.

 

This means it depends on the platform whether we can talk of native execution or interpretation. If we consider the GPL virtual machine as the platform, GPL is natively executed. If the platform is the TMS9900 CPU, GPL is interpreted.

Exactly I am being FACTUAL not BIAS!

 

Keep in mind he 9900 itself is a 990 shrunk down to a smaller single chip thus the 9900 could be considered a 990 virtual machine of the 990 mini computer.

 

To further complicate this as previously stated YOU CAN NOT USE 16 BIT WORD COMMANDS WITH VDP RAM IN THE TI99/4A.

 

After all Byte commands are counter to going with 16 bit in the first place?

Edited by RXB
Link to comment
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...