TIB: How does TI-BASIC work?
[Prev][Next][Index][Thread]
TIB: How does TI-BASIC work?
On Sat, 5 Dec 1998 02:15:35 -0500 "The Kellers" <sandia@rocler.qc.ca>
writes:
>I figure that's because with the REPEAT the calc jumps right to the
>memory address of the beginning of the loop (wich was stored in the
>stack) when it hits the END instead of searching the prog for a
>label,
>that's why I keep telling people to try to avoid GOTOs entirely. Am I
>right in assuming that in a large program, it takes even longer to
>find the label? If so It could make even more of a difference in a
>10Kb prog. Or maybe when the program is started, the memory address
>of
>all the labels is stored in some kind of table or list and GOTO
>checks
>this table for the mem address to jump to. Does anyone know?
>
>But then, is a routine with subprograms as fast as the prog I wrote
>before? I'd think not because I believe it checks a Variable
>Allocation Table or something for the Memory address of the program
>to
>call. I think I remember reading something like that somewhere a
>while
>back, but I'd appreciate it if someone could tell me if I'm right.
These are good questions. If we knew exactly how TIBASIC worked (like
what it does when it jumps, etc.), then it would help us a lot in making
faster, smaller programs.
This is how I understand TI-BASIC to work, but please remember to take
this with a grain of salt, because some or all of it is probably
incorrect....
When you first edit a BASIC program and then save it, the program is
saved in RAM exactly as it was entered (almost like a String var). When
you run the prgm for the 1st time you'll get a 'busy' animation as the
calc runs what I think is called a PARSER. The Parser goes through the
BASIC code and makes some quick changes to the prgm so that the TI-BASIC
Compiler can understand and execute the code. You may have noticed that
after you run a BASIC prgm after editing, the size of the prgm var
shrinks. This is because when the code is parsed, the parser replaces
BASIC commands with hex code. If you edit the prgm again, the code is
unparsed so you can understand it. Here is an example:
Original prgm code: (52 bytes)
:ClLCD
:Lbl A
:Disp "HELLO
:Disp VAR
:Goto A
Code after PARSING: (37 bytes) ("%"=hex code I couldn't type)
= ; ClLCD
o%A• ; :Lbl A
o+–HELLO• ; :Disp "HELLO
o+5VAR ; :Disp VAR
o%••A• ; :Goto A
Some interesting things to note:
1.) Notice that the "VAR" variable comes after a "5". The parser seems
to put a number which is the size of the variable name +2, before every
variable called in the program (regardless of var type). I think it
would be safe to say that the parser leaves the name of the var and the
length so it can search the VAT. This also means that using variables
saves on prgm size but may decrease speed. (Ans is not treated like a
var)
2.)Notice how the parser leaves the letter "A" in the code for the LBL
and GOTO commands. I am positive that this is so the compiler can search
through the prgm and find the LBL. BASIC language on a PC searches every
line starting from the first one, until it finds the Label. I don't see
why TI wouldnt do the same thing.
3.) All strings seem to be 0 terminating strings (like you care ;-) )
4.)Oh, one more thing I found out. While it may seem like your saving 2
bytes by using STOP instead of RETURN, both commands are parsed to 1 hex
code, making them use exactly the same amount of bytes. I think this is
true for other cammands.
I think the Parser ONLY changes the code for interpretation. It doesnt
check for errors or make tables of GOTO and LABELs. When you run parsed
BASIC code, the compiler is called. The compiler (or whatever it is
called) is so painfully slow because I think it compiles and executes 1
line at a time :-P, plus it has to search the VAT, check for errors, and
whatever else it does.
I would agree that Goto's should be avoided as much as possible, as well
as MENU( commands which also use Goto's.
It is slow to call a Subprgm b/c you have to search the VAT, but that
does not take that long. Once you get into the subprgm things will speed
up. Subprgms have their good and bad points.
I hope I didn't bore everyone to death ;-).
If anyone else knows anything about how BASIC executes, let me know.
Also let me know if I'm correct or way off in space....
~Philip
------------------------
pmadsen@juno.com
___________________________________________________________________
You don't need to buy Internet access to use free Internet e-mail.
Get completely free e-mail from Juno at http://www.juno.com/getjuno.html
or call Juno at (800) 654-JUNO [654-5866]