about GOTO command

BESQUEUT

Senior Member
I recently answered a help request for a 11 lines program.
In that one, I "only" saw 8 GOTO commands so I wrote :
Please, forgot GOTO command wich is only a good way to write confusing and erroneous program...

As someone said that "there is nothing wrong with using GOTO.", I submitted that code :
Code:
main:
b1=0
do
	inc b1
	GOSUB Routine
loop

Routine:
	if b1=5 then GOTO Main
return
And I suggest not to use GOTO command.
But I did not saw any answer.
Maybe am I wrong ?

What is your opinion about this command and the above code ?
 

techElder

Well-known member
A GOSUB command pushes an address onto a stack in memory.
A subsequent RETURN pulls that address back off the stack.

The GOTO Main command skips the RETURN and thus leaves an address on the stack.
Apparently by doing this, the stack runs out of room and causes a running program to have a problem.
 

BESQUEUT

Senior Member
A GOSUB command pushes an address onto a stack in memory.
A subsequent RETURN pulls that address back off the stack.

The GOTO Main command skips the RETURN and thus leaves an address on the stack.
Apparently by doing this, the stack runs out of room and causes a running program to have a problem.
Very clever, and thanks for your answer.
But is it preferable to explain that to a beginner
or to suggest not using GOTO command until he is able to understand ?

The above code in intentionaly very simple. But in a real program, it can be very dificult to detect such problem as the program may run very well for a long time, and bug sudently without any visible reason. (and a real Picaxe never say "stack overflow" it only stop running...)
 

AllyCat

Senior Member
Hi,

Certainly one should (almost) NEVER use a GOTO out of a subroutine, but the OP in the original thread wasn't using any subroutines! Certainly his wasn't a very "elegant" program, but there are plenty of novices on this forum (and some far worse coding examples!). ;)

Yes, it's generally better to encourage the use of higher-level constructs for simple programs. But don't forget that GOTO is effectively the ONLY instruction available for flow control in PIC Assembler; and AFAIK the PE converts all the higher-level constructs into GOTOs when downloading to the interpreter anyway.

Personally, I sometimes still use (conditional) GOTOs, because I "know" that a "true" conditional jump takes around 1.2ms (at 4MHz) and a "false" jump (fall-through) takes around 800 us. I can be much less certain of the time delays when using DO ... WHILE/UNTIL ... LOOP etc. (let alone SELECT ... CASE ..) constructs if I'm doing some time-critical bit-banging.

Cheers, Alan.
 

techElder

Well-known member
Oh, I see you were just trying to be clever, too. Maybe you should change your name to Chief Inspector Jacques Clouseau.

Very clever, and thanks for your answer. But is it preferable to explain that to a beginner or to suggest not using GOTO command until he is able to understand ?
 

SAborn

Senior Member
The GOTO Main command skips the RETURN and thus leaves an address on the stack.
Apparently by doing this, the stack runs out of room and causes a running program to have a problem.
That is not quite correct, it can cause problems in the simulator, but not in a real chip, if the stack is filled then the first entry in the stack is lost out the bottom when another entry is added.

This can cause problems if you try to do many gosubs deep and can result in returns to wrong places or missing returns to places altogether, but for small gosub routines to skip a return is not a problem as long as you dont go that deep in the stack for future returns.

As the stack reads from top (last entry) to bottom there is no real problem with over filling the stack with redunant entrys.
 

lbenson

Senior Member
"Used appropriatly, and with care, there is nothing wrong with using GOTO"
But the problem is that as programs grow more complex, it becomes much more difficult, especially for beginners, to use GOTO with appropriate care, and more difficult still for anyone other than the original programmer to understand what is going on. For personal use, for a hobbyist, that's not a problem until one starts to confuse oneself, but if one wants to learn to code professionally, it's best to learn to use code structures which make maintenance by others, or by oneself in the future, easier to understand. Certainly there are cases where a need for speed dictates the use of GOTO, but that's not usually the case with the picaxe.

(I know I risk adding fuel to the fire which BESQUET has started.)
 

jims

Senior Member
Hi,

Certainly one should (almost) NEVER use a GOTO out of a subroutine, but the OP in the original thread wasn't using any subroutines! Certainly his wasn't a very "elegant" program, but there are plenty of novices on this forum (and some far worse coding examples!). ;)

Yes, it's generally better to encourage the use of higher-level constructs for simple programs. But don't forget that GOTO is effectively the ONLY instruction available for flow control in PIC Assembler; and AFAIK the PE converts all the higher-level constructs into GOTOs when downloading to the interpreter anyway.

Personally, I sometimes still use (conditional) GOTOs, because I "know" that a "true" conditional jump takes around 1.2ms (at 4MHz) and a "false" jump (fall-through) takes around 800 us. I can be much less certain of the time delays when using DO ... WHILE/UNTIL ... LOOP etc. (let alone SELECT ... CASE ..) constructs if I'm doing some time-critical bit-banging.

Cheers, Alan.
Alan... Is'nt that a GOTO within the simple subroutine in his code in POST #1?? JimS
 

AllyCat

Senior Member
Hi Jims,

I was referring to the original thread to which BESQUEUT alluded. :

I recently answered a help request for a 11 lines program.
In that one, I "only" saw 8 GOTO commands so I wrote :
Please, forgot GOTO command wich is only a good way to write confusing and erroneous program........
Sorry, I was lazy then and didn't look up the link to that thread, which is here. It was BESQUEUT (in #11) who introduced code with a GOTO out of a subroutine. ;)

Cheers, Alan.
 

BESQUEUT

Senior Member
(I know I risk adding fuel to the fire which BESQUET has started.)
If I did, it was not my intention.
That is not quite correct, it can cause problems in the simulator, but not in a real chip, if the stack is filled then the first entry in the stack is lost out the bottom when another entry is added...
Did not know that ; thank you. So it is not as serious as I thought.

Thanks for all yours advices. Very instructive.

By the way : I have posted a a remark about signed arithmetic in "code snippet". No answer from matherp. Do you news from him ?
 
Last edited:

techElder

Well-known member
IMHO, if it isn't going to work, then it is serious.

The whole point is that programming is an art, so there are many ways to accomplish something.

Having said that, we are at the mercy of the designers of our canvas and paint.

We can mix oil-based paint and watercolors on one canvas, but for how long?

How long will it be before the error in procedure shows up?
 

AllyCat

Senior Member
Hi,

By the way : I have posted a a remark about signed arithmetic in "code snippet". No answer from matherp. Do you news from him ?
Yes, he "started his own fire" with this thread, so you might not hear from him. ;)

Certainly, the use of GOTOs can permit the construction of the most appalling lumps of code. But for me, the factors which really inhibit good program reliability and readability are the apparently rather "weird" syntax (e.g. the need for "pinsc.2" and semi-arbitrary use of commas and braces), and the lack of true "high level" features such as negative numbers, local variables, parameter-passing and error-handling, etc.. IMHO PICaxe Basic is nearer to Assembler than to a true high-level language, but perhaps that's why I quite like it. :)

Cheers, Alan.
 

Buzby

Senior Member
... IMHO PICaxe Basic is nearer to Assembler than to a true high-level language, but perhaps that's why I quite like it. :)
PICAXE BASIC has a very high level of integration with the peripheral hardware of the underlying PIC. ( Just think how much assembler is needed to handle IRIN/OUT, HI2C, PULSIN, TIMER, COUNT, etc. Even the simple HIGH and LOW hide a mess of bit-twiddling from the end user. )

So I don't consider it akin to assembler, more like a targeted subset of BASIC which has implemented simplicity at the expense of language features.

Regarding the use of GOTO, I can write ( and often do ) an appalling lump of code without using a single GOTO !.

I don't think the lack of language features has any effect on reliability or readability, these are both the responsibility of the programmer.
 

bpowell

Senior Member
I'm curious: What would happen with the code in Post #1? Granted, it'll keep putting a return-address onto the stack until the stack overflows...but my understanding is: PICAXE does NOT enable the Stack Overflow Reset feature of the PIC...and that the PICAXE would just "Loop around" in the stack...given the program in Post #1...I think the entire return-stack would be full of the same address...so I think the code in POST 1 would work just fine...albeit from luck, rather than design...but it should still operate as intended.
 

inglewoodpete

Senior Member
As a professional programmer, I understand there are many, many ways to write workable code. When enhancing or debugging other programmer's code I find there are code structures with a wide range of "ease of understanding". Even if I have to rework code that I wrote myself 10 or 20 years ago, I can see that my own style has evolved with experience.

With PICs in general and PICAXEs too, there are all sorts of quirky things that can be done to get a result or solution. However, the risk of unknown outcomes (eg when playing with the stack) or future programmer misinterpretation of quirky code is real. I have a developed my personal style of programming for PICAXE that may, at times, be seen to be inefficient but that inefficiency is unimportant in the context it is used in.

And, to get back on thread, I have an aversion to the GoTo command. No amount of medication seems to help alleviate the rash I develop when I encounter these commands in code.:)
 

techElder

Well-known member
Dang it erco, that is like that little song ditty that you can't get out of your head for days at a time. I just have to keep coming back here to look at it again!
 

Buzby

Senior Member
I've always known of the abhorrence of GOTO , but never really knew why.

After reading the Dijkstra document above I think I now see why.

Dijkstra had worked on automated systems for formal proof of software functionality. Part of these systems was an automatic way of giving every instruction in the the program a unique reference, which indicated it's 'position' in the process flow of the code. This was easy if every instruction was 'contained' in a DO...LOOP or a FOR..NEXT etc.. Because a GOTO could make it very difficult to automatically calculate a 'position' for every instruction, I can see why Dijkstra hated them.

But is 'difficult to formalise' a good enough reason to completely avoid using GOTO ?.

Dijkstra also wrote in the same document, "The exercise to translate an arbitrary flow diagram more or less mechanically into a jump-less one, however, is not to be recommended. Then the resulting flow diagram cannot be expected to be more transparent than the original one."

This is an important point. A program using GOTOs may be easier for a human to understand, but a real pain for a machine to analyse.

Food for thought ?
 

lbenson

Senior Member
A program using GOTOs may be easier for a human to understand, but a real pain for a machine to analyse.

Food for thought ?
Thought: Let the machines do the hard work. (And thanks, Rev-Ed, for the hard work which makes it easy for us.)
 

bpowell

Senior Member
I'm curious: What would happen with the code in Post #1? Granted, it'll keep putting a return-address onto the stack until the stack overflows...but my understanding is: PICAXE does NOT enable the Stack Overflow Reset feature of the PIC...and that the PICAXE would just "Loop around" in the stack...given the program in Post #1...I think the entire return-stack would be full of the same address...so I think the code in POST 1 would work just fine...albeit from luck, rather than design...but it should still operate as intended.
FYI: I've thrown that code on a 08M2...while it DOES bonk (stack overflow) in the Simulator, it runs just find on the chip...again, this clearly is overflowing the stack...but since it's the same return address every time, it appears to be okay. Not best-practice certainly...but I was curious ... thought I'd share.
 

premelec

Senior Member
@erco I like your GOGOTOTO program - with the [im]proper indentation and spacing it could be a new kinetic art endeavor!
 

erco

Senior Member
Have at it, fellas! Cut, paste, indent, mod, and simulate freely. My coding equivalent of a Useless Box.

Code:
aa:goto zz
bb:goto yy
cc:goto xx
dd:goto ww
ee:goto vv
ff:goto uu
gg:goto tt
hh:goto ss
ii:goto rr
jj:goto qq
kk:goto pp
ll:goto oo
mm:goto nn
nn:goto aa
oo:goto mm
pp:goto ll
qq:goto kk
rr:goto jj
ss:goto ii
tt:goto hh
uu:goto gg
vv:goto ff
ww:goto ee
xx:goto dd
yy:goto cc
zz:goto bb
 

geoff07

Senior Member
After Edsger Dijkstra wrote his "Goto considered harmful" paper in 1968 there was a tongue-in-check suggestion in 1973 that instead there should be a 'come from' command:

http://en.wikipedia.org/wiki/COMEFROM

It would not really have helped ensure that the code path was deterministic, which is the problem with the Goto alone, in that reading code with gotos does not tell you the execution path, which becomes data-dependent. Not being able to tell the path from the code rather limits understanding and thus maintainability. Not a problem if it is your code but a big problem if someone is paying for maintenance.

The original Dijkstra paper is worth a read (linked in a post above).

Dijkstra is considered the father of Structured Programming, which is the art of abstraction and using simple and clear constructs in layers, and quite a different thing to the use of software as a surrogate for hardware and gotos for jumper wires.

Interestingly, in the UK, since last September, we now teach programming to all children from age 5 to 18. They begin with simple concepts and progress to learning Scratch before moving on to html and python etc. Scratch is a very powerful graphical way of writing code, and can even interface with hardware (e.g. Lego robots). Scratch (from MIT, v1.4 is free to download and use) has all the normal code constructs but no concept of the goto. Some of the ten-year-olds that I teach are quite frighteningly clever with code.
 

stevesmythe

Senior Member
To add to Geoff's comments, Revolution Education have just developed Scratch2Picaxe ("S2P"), which allows children (and their Dads ;) ) to interface motors, sensors etc. via a Picaxe with the excellent Scratch programming environment.

[edit]
Note that Scratch 2 or later must be used if you want to use S2P
[/edit]
 
Last edited:

srnet

Senior Member
For a balanced view of the GOTO To debate I suggest that you read the Wiki page on the subject.

http://en.wikipedia.org/wiki/Goto

Dijkstra comments in the early 70s have achieved almost cult like status, but as the Wiki article highlights, there are many who do not agree, some comments from that article that are of note;

“An alternative viewpoint is presented in Donald Knuth's Structured Programming with go to Statements, which analyzes many common programming tasks and finds that in some of them GOTO is the optimal language construct to use”

“In their quasi-standard book on the C programming language, Dennis Ritchie and Brian Kernighan warn that goto is "infinitely abusable", but also suggest that it could be used for end-of-function error handlers and for multi-level breaks from loops.”

“Other programmers, such as Linux Kernel designer and coder Linus Torvalds or software engineer and book author Steve McConnell, also object to Dijkstra's point of view, stating that GOTOs can be a useful language feature, improving program speed, size and code clearness, but only when used in a sensible way by a comparably sensible programmer. According to computer science professor John Regehr, in 2013, there were about 100,000 instances of GOTO in the Linux kernel code”

What happens all too often is that the anti GOTO side of the disagreement seek to suggest that that there is a form of universal truth that GOTOs are bad, should not be used or even worse banned altogether when clearly lots of experts in the field seem to disagree.
 

lbenson

Senior Member
I don't think that anybody here has suggested that GOTO should be banned, and I certainly agree with the Kernighan & Ritchie suggestion that in complex code, GOTO may be the clearest code "for end-of-function error handlers and for multi-level breaks from loops". And I can easily understand that Linux kernel code could have many instances of these.

On this forum, it is rarely the case that the posters having problems with programs which contain GOTOs are facing those conditions. They are having problems with the flow of logic in their programs, and they are likely to reduce those problems if they learn the "structured" techniques for managing flow control.

That said, many picaxe programs are small enough so that GOTO can be used without adverse consequence with regard either to flow control or readability. But it is not hard, as a program grows, to cross over the line and find that one has woven a tangled web.
 

geoff07

Senior Member
This isn't a theological discussion, and as Dijkstra recognised, and others have also pointed out, it is clear that there is a place for the goto construct. There is at least one place in Picaxe Basic where it is the only possible solution. If maximum execution speed is the goal (not so common with microcontrollers, always true in the Linux kernel) then gotos can be faster than alternatives. But to make good use of them requires experience, and if speed was the issue you wouldn't be using an interpreted language.

Many novices post programs on this forum and ask for help, where their code is quite incomprehensible due to lack of any kind of structure, probably reflecting a lack of a design before coding. Whilst this may be fun, it isn't much of a learning experience. For these, we do have some responsibility to point out modern best practice. By specifically avoiding the use of gotos, you are forced to create a proper structure and to understand the flow of control in a program. Very quickly, you discover they are unnecessary anyway.
 

stevesmythe

Senior Member
Having been programming in a variety of languages for the best part of 40 years before coming across Picaxe Basic, I was a bit surprised to see so many code examples in the Picaxe manuals using the following program layout:
Code:
main:
do
.
if .. then
.
endif
.
loop
.
etc.
[B]goto[/B] main
As a Picaxe beginner relatively recently, I started using "goto"s (against my better instincts) largely because of the proliferation of such examples in the manuals. It is only when I studied longer and more complicated (better-written) code examples, such as those provided by experienced members in this forum, that I realised I'd started to pick up bad habits!
 

srnet

Senior Member
This isn't a theological discussion, and as Dijkstra recognised, and others have also pointed out, it is clear that there is a place for the goto construct

From the 11th commandment that Dijkstra published, the quote appears to be;

"More recently I discovered why the use of the go to statement has such disastrous effects, and I became convinced that the go to statement should be abolished from all "higher level" programming languages (i.e. everything except, perhaps, plain machine code)

Did he change is mind, and if so why ?
 

BESQUEUT

Senior Member
Many novices post programs on this forum and ask for help, where their code is quite incomprehensible due to lack of any kind of structure, probably reflecting a lack of a design before coding. Whilst this may be fun, it isn't much of a learning experience. For these, we do have some responsibility to point out modern best practice. By specifically avoiding the use of gotos, you are forced to create a proper structure and to understand the flow of control in a program. Very quickly, you discover they are unnecessary anyway.
I agree 100%
 

BESQUEUT

Senior Member
Thanks everyone - you've just answered why I got "STACK OVERFLOW" in my code!!!!
Happy to help you !
Maybe, you can publish your code "before" and "after" and explain where was the problem...
This will certainly be usefull for others...
 

Goeytex

Senior Member
Who appointed Dijkstra the High Priest of Programming? Who placed him on Mt Olympus as the god of structured programming? Seems to me that he was not lacking in ego and arrogance [ common with intellectuals and programmers] an and took his own opinions too seriously, as do his misguided glassy-eyed sycophants. .

As you may have gathered from the above statement I am not a Dijkstra worshiper and have little tolerance for those who are. I have even less tolerance for those who would attempt force a dogmatic and religious approach to programming upon hobbyist playing around with a Picaxe.

I am not a fan of excessive use of the "evil" GOTO statement. Anyone with a smidgeon of experience and average intelligence can see how bad and unintelligible code can become with the improper and excessive use of GOTO.

However, to suggest "banning" GOTO from "all higher level languages" was absurd and over the top. Who did Dijkstra have in mind to enforce this ban? Maybe there should be a GOTO Gestapo? Or a GOTO Inquisition? Maybe some burnings at the stake? I read not too long ago where someone here said he got physically sick when he saw a goto in code. How ridiculous and how sad. Best stay away from the Picaxe manuals or risk a possible slow and agonizing death.

Let me also point out to the Dijkstra worshipers and GOTO bullies that may frequent these forums that Dijkstra was also against the use BASIC. So some repentance may be in order. Repent heretics !

I'll leave you with this. Dijkstra wrote to Donald E. Knuth in a personal correspondence and said:

Please don't fall into the trap of believing that I am terribly dogmatical about [the go to statement]. I have the uncomfortable feeling that others are making a religion out of it, as if the conceptual problems of programming could be solved by a single trick, by a simple form of coding discipline!"
 

inglewoodpete

Senior Member
Let me also point out to the Dijkstra worshipers and GOTO bullies that may frequent these forums that Dijkstra was also against the use BASIC. So some repentance may be in order. Repent heretics !
I formed my opinions on the Goto statement without even knowing of Dijkstra and his preachings. I like structure in the programs that I work on.

Besides, I come out in a rash when I see Goto statements:). Ok, Ok I have used Gotos in 3 PICAXE programs that I have written in the last 10 years.
 

techElder

Well-known member
Ok, ok. Since we're having a "coming out" party, I used a GOTO in my latest project. (Now recite 3 hail mary's and get back to work.)
 

Goeytex

Senior Member
I thought anyone over 50 knew about Dijkstra and his anti-goto/ anti-BASIC leanings. It became almost cultic in the 70's. Still is.

I hope the humor was not lost in my post. I am all for structured programming. I Like it. Anyone looking at the code I have posted here over the years can see that I rarely use GOTO. The exceptions mostly being 5 line examples for newbies or an occasional skip in a sub.

We've all seen un-commented spaghetti code laden with GOTO's posted here, code that is near impossible to decipher. And I certainly agree that this kind of coding needs to be avoided. However, I've been around long enough to realize that some folks simply don't care about pretty structured/commented code. They just want to get their little gizmo working. Often they do not realize how difficult is is to help them get the code working when they ask for help. However I've also been around long enough to realize that no amount of browbeating will get some of these folks to change.

We must realize that they are not employees that can be forced to comply with the threat of job loss, or students that can threatened with a failing grade. Most are hobbyists and tinkerers. And yes, some are even bone-headed, ignoring good advice. Yet, bone-headed instance of compliance to a not-so-standard "standard" does not seem to help.

What irks me is when rigid folks DEMAND others do things their way when another way might work just as well.
 

inglewoodpete

Senior Member
I thought anyone over 50 knew about Dijkstra and his anti-goto/ anti-BASIC leanings. It became almost cultic in the 70's. Still is.
Yes, I'm well over 50 but am largely self-taught when it comes to programming. I studied Electronic Engineering back in the 70s. I developed my attraction to structured code prior to reading the preachings of Dijkstra.

People can code any way they want. However, if they want help, I will choose whether to help them depending on how easily I can read the code they have already written. As simple as that.
 
Top