Re: TIB: If-then-goto-end loops can create a problem


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

Re: TIB: If-then-goto-end loops can create a problem




Hello,

Yes, I agree with what you said. But you can branch out of if/then/end
loops without getting MEM errors:

Lbl START
If 1
Then
Goto START
Else
Goto START
End

This will definately create a MEM error, because it is "filing up" the
stack, like you said. Getting around it is pretty obvious, once you
think about it: You have to make the parser (or whatever) hit an 'End'
for every time it hits an 'If', but you can't make it hit an 'End' if
it didn't hit an 'If'. So just put the label you intend to jump to
inside it's own if/then/end loop:

If 0
Then
Lbl START
End

Do that with the program above and it will run indefinately without an
error. It will always get to an 'End' after an 'If'. I put '0' as an
argument for 'If' so that it doesn't bother to get into the loop,
don't know if this makes a difference, don't care...

But unfortunately, this approach causes another problem: What happens
when there's a 'Goto START' that isn't inside a loop? You get an error
because an 'End' will be reached before an 'If'.

The solution to that problem? Just make a loop for 'Goto START' to
avoid it!

If 1
Then
Goto START
End

There you have it! How to branch out of loops without ever getting
memory errors!

Of course, this all bloats your prog and usually just makes your prog
more complicated. In my experience, you can always, or almost, avoid
using 'Goto' statements. And you should avoid them because they are
slow (I'm not gonna repeat the explanation for the reason unless
anyone cares), the speed difference can be pretty important...

So, Jason, in the end I agree with you:

> Just y'all try avoid branching out of "IF-Then" statements with
"Goto"s

And, you sould try to avoid 'Goto's alltogether!

Philipp Keller


> Somebody wrote:
>
> >  >>Using Goto statements in an If-Then-Else-End statement will
cause
> >  >>the calc
> >  >>to gradually run out of mem because the End command will never
> >  >>be reached.
> >  >>The same applies to If-Then-End statements.
>
> Yes, I think we've established this is true, and many of you have
posted
> example sections of code explaining how to get around it, yet these
> conditional statements are specific to the programmer's game, and
they will
> figure out the best series of "If-Then" statments... Well, I have a
theory as
> to why the calc responds by slowing down or giving a memory error,
when jumps
> are made out of the conditional statements... The Basic program must
make use
> of the Stack within the RAM of the calculator, and it is frequently
used in
> ASM.  The Stack is a structure that you can save values to, but
mostly
> addresses when you branch out to a subroutine, and then it removes
the
> address to know where to go after the subroutine is done. It has a
"First In
> / Last Out" system, and I'll use the analogy of a stack of plates.
If you put
> a plate down, and one on top of it, you would have to remove the top
plate
> first to get to the one you put on first, right? Well, lets see how
this
> relates to Basic programs... If you had an "IF-Then" statement, and
put
> another "IF-Then" statment inside of it, the calc expects 2 "End"
statements
> to signify the stopping of that conditional.  Well, that first "End"
that it
> encounters after both "IF-Then" Statements, cancels out the second
"If-Then"
> you made, not the first, yet the next "End" will cancel out the
first one,
> therefore showing the "Last-In / First Out " system... Anyways, back
to why
> "Goto" statements cause a problem. When a conditional statement is
made,
> there must be something that tells the calc to keep executing the
commands
> after an "IF-Then" statement only if that conditional was true. And
when the
> calc gets to an "End" statement, it knows to halt the conditional
checking,
> and remove that value or whatever from the Stack. If the program
reaches a
> "Goto" within the "IF-Then" statement, it will never get to that
"End" and
> keep pushing values down onto the stack upon every new "IF-Then"
statment,
> and if your program is doing those through a Loop, it will start
building up.
> I believe there is a set maximum for the number of values the calc
can save
> in its RAM on this stack structure, and once it reaches this limit,
it will
> give a memory error. The calc may slow down because it has difficult
handling
> all these conditionals and sorting them out... I dunno, Im just
speculating
> all of this due to my current level of ASM knowledge, but I doubt
very few
> people besides the people at TI, actually know what goes on during a
Basic
> program, involving the parser and translating all of these commands,
its a
> very difficult process. Hmm, im going to stop thinking about it so
much.
> Just y'all try avoid branching out of "IF-Then" statements with
"Goto"s, it
> will just suck for the calc after a while... =P
>
> Jason_K - TCPA Member
> http://tcpa.calc.org/
>



References: