[Gambas-user] usage of too much GOTO can be bad pracitce or make influence in the code?

[Tobias Boege]

PICCORO, read this mail at your own risk. I won't accept invoices for
wasting your professional time.

On Sun, 25 Jun 2017, PICCORO McKAY Lenz wrote:
> due to many inconsistence responses i must spend time (again) to
> investigating..
> 
> the problem of goto comes from C to object conversion compilation..
> 
> many goto's produce many labels and "jump"'s in assembler code translation
> when a C program are compling.. so the resulting program will be more
> slower due too many "jumps"
> 
> this are poor ilustrated to most of users here in the list due i think
> nobody here know (in experience) code in assemble like me..
> 

Oh wow, that's a high footstool you're sitting on.

> so i'm very frustrating due when i try to use gambas in professional way
> (due are very promisess and usefully) many questions require spend of time
> due situations like that... please users.. dont make conjetures of things
> that not known, causes spend of time of otheers
> 

What most people talked about were the usual readability concerns which
are the first thing that's brought forward in every one of the countless
"GOTO considered harmful" essays out there. Supposing you asked a general
question about good practices regarding GOTO (which you were, just look
at your opening message!) they also said that it was up to personal
preference in the end. Therefore I don't see the too many inconsistencies
you speak of.

The only one who said anything about performance, which you bring up above,
was nando:

> Sometimes GOTO is needed...especially if you want your code to run faster.

and here I agree with you. The last part is certainly debatable and depends
on the platform (using goto in C is wildly different from using GOTO in
Gambas, see below). *The* standard example, and *perhaps* what he thought
of, is jumping out of 4 nested loops without GOTO. You can do it but at
least the obvious two solutions introduce new functions (i.e. calls and
returns) or some more IFs, both of which are forms of jumps.

> i case of gambas analizing the code seems are not the same.. due gambas
> fist make their own bycode that runtime inderstand and then that runtime
> pass to object mahine.. so many things change and its not the same... in
> easy words..
> 

Exactly, so why do you think your concerns about pipelining and branch
prediction at the C -> machine level are relevant at all in Gambas?
The program execution loop in the interpreter is a gigantic jump table.
The execution of every instruction in a Gambas program involves at
least two goto's in C, while the actual Gambas GOTO instruction is
implemented as an arithmetic operation on the program counter!

And no, I'm not conjecturing this; it's right there in the source code.
It should be natural that you read it if you require a deeper understanding
for your professional tasks than what others can provide. Your time is
not more precious than anyone else's on this list.

On a tangent I'm surprised nobody took the opportunity to scold Benoit
in this thread yet :-) Have you never tried modifying one of his parsers,
e.g. gb.markdown:

  $ cd ~/src/gambas3/comp/src/gb.markdown/.src
  // Count non-empty, non-comment lines
  $ egrep -cv "^[ ]*'|^[ ]*$" Markup.module
  798
  // Count labels, GOTO and GOSUB lines which are not commented out
  $ egrep -i ":[ ]*$|GOTO|GOSUB" Markup.module | grep -cv "^[ ]*'"
  75
  // Percentage of directly GOTO-related lines in the markdown parser
  $ pcalc 100*75/798
        9.398496240601503       0x9                     0y1001

Regards,
Tobi

-- 
"There's an old saying: Don't change anything... ever!" -- Mr. Monk