That's why TI BASIC is so slow!

[senior_falcon]

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

 

I can think of at least one!

[RXB]

To further muddy the water, or cast other perspectives on the matter of Why TI BASIC is so slow.

 

We did some opcode frequency statistics here. Only to show that the nice 16-bit CPU apparently ends up spending a lot of time "moving bytes".

 

This is 100% got to do with AMOUNT OF RAM AVAILABLE.

 

Look if the 9900 did all work as 16 bits it would need 8 times the memory as to avoid doing BYTE COMMANDS instead only using WORD COMMANDS.

 

Can you imagine the memory required to only use words all the time in a machine with only 256 bytes of RAM? (128 Words!?)

 

TI committed to VDP memory for price, then committed to byte vs word on a 16 bit CPU, then committed to a 4 cycle read before write.......and the list of problems goes on and on from there.

 

And you want to blame GPL for all of this????? REALLY? When is the hardware design that created all of this going to be addressed?

Edited April 27, 2017 by RXB

[senior_falcon]

Let me muddy the water a little bit on the issue of whether a language is interpreted. Consider the following snippets of two programs:

BL @HCHAR

DATA ROW,COL,CHR,RPT

BL @VCHAR

DATA ROW1,COL1,CHR1,RPT1

 

HCHAR code to perform hchar operation and return to next line

VCHAR code to perform vchar operation and return to next line

 

Now this which starts with R13 pointing to the first statement:

LP MOV *R13+,R12

BL *R12

 

DATA HCHAR,ROW,COL,CHR,RPT

DATA VCHAR,ROW1,COL1,CHR1,RPT1

 

HCHAR code to perform hchar operation and return to LP

VCHAR code to perform vchar operation and return to LP

To me the first is written in assembly and the second one interpreted, but the difference between them is very small. What do you think, and why?

Edited April 27, 2017 by senior_falcon

[sometimes99er]

To me the first is written in assembly and the second one interpreted, but the difference between them is very small. What do you think?

 

Agree.

[+mizapf]

An interpreter holds a set of predefined behaviours (possibly as subroutines), usually implemented in a native way with respect to the platform, that are selected and executed according to a given data element. An interpreted program is a sequence of those data elements, processed by the interpreter.

 

As for the code snippet from above, you would usually have some requirements for the "interpreted language"; otherwise any collection of data may be considered as being "interpreted" by reading and branching to some location. For instance, you could require the interpreted language to be Turing-complete, which implies that you can create loops or check conditions.

Edited April 27, 2017 by mizapf

[+chue]

The result of writing code in assembly, C, GPL, or BASIC is that you get a file that has binary (machine) code in it. The difference is that some binaries are executed natively by the CPU, and the others need some kind of software CPU (or VM) to execute the code.

 

So we have these executing natively on the hardware CPU: C and assembly

 

This executes using a software CPU on top of the hardware CPU: GPL

 

Finally, we have BASIC which executes inside of a software CPU (BASIC interpreter), which is built on top of another software CPU (GPL), which runs on the hardware CPU (9900).

 

Generally speaking, BASIC will be slower than GPL, which will be slower than C and assembly.

Edited April 27, 2017 by chue

[JamesD]

I'm just trying to figure out why anyone would think I'm talking about comparing the speed of source code.

[+mizapf]

So we have these executing natively on the hardware CPU: C and assembly

 

Ehm ... I dare to object.

 

C is clearly not a native language; neither is assembly language, strictly speaking. Machine code is native code. C is a high-level language (could also be considered platform-independent) that must be compiled to machine code, typically with a stopover at assembly language.

[+chue]

 

Ehm ... I dare to object.

 

C is clearly not a native language; neither is assembly language, strictly speaking. Machine code is native code. C is a high-level language (could also be considered platform-independent) that must be compiled to machine code, typically with a stopover at assembly language.

 

OK you got me... add the word "output"

 

The output of C and assembly are executed natively...

[JamesD]

 

OK you got me... add the word "output"

 

The output of C and assembly are executed natively...

If the C compiler outputs assembly, you still have to assemble it.

​A few Small C compilers output bytecodes for an interpreter.

A C compiler could also output GPL.

[Asmusr]

Has anyone thought about a BASIC compiler that would output GPL?

[JamesD]

Has anyone thought about a BASIC compiler that would output GPL?

This is the short list of pros and cons I came up with for that.

 

1. The interpreter is built into the machine, so the runtime package could be smaller.

2. It would probably let you build carts with BASIC, though you can probably do that either way with a little code.

3. You could run code out of video RAM, so it would work on an unexpanded TI.

4. Code would be slower than from a compiler that uses a different bytecode interpreter and 16 bit RAM.

5. Limited RAM

6. Expanded features couldn't fully take advantage of the VDP.

 

I think #3 is the biggest positive but that leads to 4, 5, and 6.

I seem to remember other BASIC compilers offering at least a 30% speed increase just due to the elimination of the parser.

I'd guess the TI could see a similar speed increase, but that would still make Ahl's benchmark slower than a 1MHz Apple II interpreting code.

You'd need a 50% speedup to even be competitive. I suppose fewer VDP accesses could translate to a greater speed increase though.

[matthew180]

Ehm ... I dare to object.

 

C is clearly not a native language; neither is assembly language, strictly speaking. Machine code is native code. C is a high-level language (could also be considered platform-independent) that must be compiled to machine code, typically with a stopover at assembly language.

Assembly is native. Assembly is a direct representation for machine code using mnemonics. An assembler does a direct translation of each individual instruction to the binary opcode. In assembly there is no interpretation, syntax tree, etc. that goes on with higher level languages. Just because I used a tool to replace MOV R1,R2 with 1100000010000001 does not mean I'm not programming in the native language of the CPU.

[Tursi]

Has anyone thought about a BASIC compiler that would output GPL?

 

I have a very rudimentary tool that translates a subset of XB into GPL. I used it to create the menu for the MPD.

 

It used to be on my website, but after the server crash I didn't feel it was complete enough to be useful to anyone else.

[Tursi]

Assembly is native. Assembly is a direct representation for machine code using mnemonics. An assembler does a direct translation of each individual instruction to the binary opcode. In assembly there is no interpretation, syntax tree, etc. that goes on with higher level languages. Just because I used a tool to replace MOV R1,R2 with 1100000010000001 does not mean I'm not programming in the native language of the CPU.

 

I'd agree. Unless you're programming with toggle switches on the data bus, you're still using an intermediary representation to convert whatever you typed into the instructions loaded into the RAM chip. "C081" is no more meaningful to the CPU than "MOV R1,R2". Even "1100000010000001" is meaningless - that's a string of 16 bytes. It's closer to the native representation, but only to humans. So it's getting pretty nit-picky at that point.

 

Of course, there are macro assemblers that blur all that and allow use of structures that don't exist. There's always a blurry line - "it depends" is always the answer in computing.

 

It's interesting how this discussion comes up every couple of years. Shows the divergent ways that everyone learned about computing.

[+mizapf]

Assembly is native.

 

It is a question whether you distinguish between the representations of the language and its semantics. CPUs cannot execute assembly language because it is a textual representation of their machine language. If you say that assembly language is just another representation of machine language, you can certainly claim that assembly language is native.

 

I disagree because the assembly language may add more structures or entities that are not natively present. There are pseudo-instructions (like NOP, RT) that may be considered as being alternative representations of natively supported commands (JMP $+2, B *R11), or you can say that they are not present in the instruction set but must be replaced. Also, there are assembly directives (DATA, BYTE, TEXT, END, AORG etc.) that do not map to machine language commands. Again, depending on whether you count them to the instructions or not, you can say that assembly language is native or not.

 

[Edit (after Tursi's post showed up): Correct, you can say that the machine language always needs a representation, and if it is just a textual representation of the binary values. I just wanted to add that an assembler may add structures that have to be translated. As you said, a point of view.]

Edited April 27, 2017 by mizapf

[matthew180]

So something must take the GPL byte code and allow the CPU to run it.... What is that thing called?

 

That would be the GPL interpreter, which lives in the system ROM. The interpreter itself is written in assembly. So anything written in GPL is interpreted, and the BASIC / XB interpreters were written in GPL. Thus the infamous double-interpretation and slow BASIC / XB.

[RXB]

Has anyone thought about a BASIC compiler that would output GPL?

Yea, I was working on a GPL compiler:

 

https://www.youtube.com/watch?v=TQzp25sSa1A

 

 

This was doomed by the outright hostility to GPL in general.

Why do a project when you have a number in the community attacking GPL just because you are using GPL.

Who else has to put up with this crap?

 

The only good thing about this project was it led me to wanting to decompile and see the source of XB ROMs as that is what was required for me to finish the Compiler.

So it did lead to a new better project the SAMS RXB.

[matthew180]

It is a question whether you distinguish between the representations of the language and its semantics. CPUs cannot execute assembly language because it is a textual representation of their machine language. If you say that assembly language is just another representation of machine language, you can certainly claim that assembly language is native.

The CPU can't execute binary either, or hex, or any other representation if you want to play the *exact game*. And it certainly cannot load that information from disk into memory either. So you are saying that the only native language of a CPU is the actual electrons that cause the gates inside the CPU to change? I'm sorry, that is just ridiculous in this context. Assembly is native.

 

I disagree because the assembly language may add more structures or entities that are not natively present. There are pseudo-instructions (like NOP, RT) that may be considered as being alternative representations of natively supported commands (JMP $+2, B *R11), or you can say that they are not present in the instruction set but must be replaced. Also, there are assembly directives (DATA, BYTE, TEXT, END, AORG etc.) that do not map to machine language commands. Again, depending on whether you count them to the instructions or not, you can say that assembly language is native or not.

Data structures are not code, and neither is data itself. An assembler providing structure support (which none of the 99/4A assemblers do by the way, so you are now arguing about features we never had on the 99/4a) has nothing to do with the assembly language mnemonics. They are called "assembler directives" for a reason. Having the assembler stuff bytes into your object code, or calculate static offsets, etc. does not make it any less native. MACROS and pseudo-ops convert directly to assembly instructions (MACROS are fancy search-and-replace), and in the case of the TI's pseudo-ops (like RT, NOP, etc.), it is a one-to-one translation.

 

[Edit (after Tursi's post showed up): Correct, you can say that the machine language always needs a representation, and if it is just a textual representation of the binary values. I just wanted to add that an assembler may add structures that have to be translated. As you said, a point of view.]

 

Again, structures are not code. How you represent data in memory has nothing to do with instructions the CPU can execute. The CPU has no concept of the difference between code in memory and data, and the CPU will happily try to execute you data if it gets off track.

[+mizapf]

Assembly language is a second generation language: https://en.wikipedia.org/wiki/Second-generation_programming_language, machine language is a first generation language: https://en.wikipedia.org/wiki/First-generation_programming_language . If I remember correctly - I have to look it up, though - this is also the way it is explained in Tanenbaum's operating system text books.

 

I don't see a need to discuss interpretations of terminology too deeply. Your view, my view. Let's get on.

[+InsaneMultitasker]

Why do a project when you have a number in the community attacking GPL just because you are using GPL.

Who else has to put up with this crap?

 

The only good thing about this project was it led me to wanting to decompile and see the source of XB ROMs as that is what was required for me to finish the Compiler.

So it did lead to a new better project the SAMS RXB.

GPL is often misunderstood and under-appreciated. I was always amazed that Gazoo programmed GPL by typing the code in hex notation, no compiler in the middle. If you enjoy GPL and associated projects, then by all means continue with it!

[RXB]

GPL is often misunderstood and under-appreciated. I was always amazed that Gazoo programmed GPL by typing the code in hex notation, no compiler in the middle. If you enjoy GPL and associated projects, then by all means continue with it!

Yea Gazoo did it the really hard way by hand.

Big projects like Disk Manager 2 Cart from TI would have taken many many hours vs using the GPL Assembler and loading the Object code.

And I really am adrift in a sea of Assembly Programmers that have nothing nice to say about a language that is exactly was the selling point of the TI when I bought one....lots of cartridges (Almost all GPL).

TI Basic

Editor Assembler

Extended Basic

Mulitplan

TI Writer

Disk Manager

Terminal Emulator

Mini Memory

TI Logo

And a crap load of Game Cartridges or Educational ones!

[Casey]

I actually dabbled with GPL recently because it has always interested me (particularly with the ease of displaying screens). I'm by no means an assembly language programmer - I have played with it but have not done anything productive in it. I think the most difficult thing with learning GPL is that there isn't a native tool in the TI 99/4A environment like Editor/Assembler that you can write GPL based programs in. Even through emulation, you have to use the GPL assembler, then load it in as a cartridge or in the GRAM emulated device. I'm not even exactly sure how to execute a GPL program unless I make it seem like a cartridge.

 

I guess my point with all this - the learning curve is pretty steep.

[+Lee Stewart]

GPL is often misunderstood and under-appreciated. I was always amazed that Gazoo programmed GPL by typing the code in hex notation, no compiler in the middle. If you enjoy GPL and associated projects, then by all means continue with it!

 

Yeah, @Gazoo was a human GPL Assembler!

 

...lee

[RXB]

I actually dabbled with GPL recently because it has always interested me (particularly with the ease of displaying screens). I'm by no means an assembly language programmer - I have played with it but have not done anything productive in it. I think the most difficult thing with learning GPL is that there isn't a native tool in the TI 99/4A environment like Editor/Assembler that you can write GPL based programs in. Even through emulation, you have to use the GPL assembler, then load it in as a cartridge or in the GRAM emulated device. I'm not even exactly sure how to execute a GPL program unless I make it seem like a cartridge.

 

I guess my point with all this - the learning curve is pretty steep.

Actually my GPLHOW2 videos and files you can use show a step by step process of doing the simple to complex.

 

First demo and Video just puts HELLO on screen and moves it.

Second how to use some sprites and move them.

 

And yes GPL is not like Assembly but requires a HEADER in order to function.

The GPL header is for a DSR, or Program or even a TI Basic subroutine.

Extended Basic or RXB are actually a Program using the GPL header just like any other cartridge.

So when you create GPL you are actually making a Cartridge.

 

Now you can also make games like they did using the GPL Linker, Wumpus is an example using the Linker to load it into VDP and RAM like a normal EA program.

Edited April 27, 2017 by RXB