TIB: Re: How does TI-BASIC work?

[Prev][Next][Index][Thread]

TIB: Re: How does TI-BASIC work?



>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.

i agree completely

<snip>

>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:

This is called "tokenizing" because it replaces the commands, with a
two digit hex number or a a byte ("tokens" from 00 to ff, or 0 to 255,
each number represents a character for the calc(like ASCII)), each
representing a command. The tokenizing part does not apply to the
82(and 83, I think) because on those calcs, the commands are already
tokens.

>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

How did you get this, with a hex editor?

>Some interesting things to note:

<snip>

Yes, very

>I think the Parser ONLY changes the code for interpretation.  It
doesnt
>check for errors or make tables of GOTO and LABELs.

Didn't think so, and tatsuo pretty much proved that with his last
email.

>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.

It doesnt "compile" at all. It just executes one command after the
other, it's and "interpreted language" like QBasic. If it was
compiled, the gotos would be converted to jumps to different memory
addresses and it would be a lot faster. Yes, it must have to search
the VAT (Variable allocation table, right?) for the location of
variables, the commands check for errors just like the ones you type
at the home screen. Ans is probably a hard-coded, predifined memory
address so the calc doesn't have to look for it.

>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.

Checking the address up in the VAT is probably a lot faster that
searching for a label (in a large program anyway), so I would say that
SubPrograms are faster than gotos, but slower that other loops that
just store an address in the stack and later jump to it. So it would
be preferable to use supprograms instead of gotos if other loops just
don't cut it.

At ti-philes and ticalc.org there are some articles on "hacking" the
TI calcs, about the 82 at least. I believe I'm gonna go read those
again over the weekend to see if I can figure anything out. I remember
that there was a table that had the Hex value of each token from 00 to
ff for the 82, among a lot of other stuff...

>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....

If you are way off in space, you are not alone *L*
Philipp Keller

>~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]
>