Op Sat, 2 Dec 2006, schreef John Coppens:
> On Sat, 02 Dec 2006 08:01:04 -0500
> David Mears <[EMAIL PROTECTED]> wrote:
>
> > From the first pascal program that I wrote in the late 80s to today,
> > I've only used Goto once and that was because I was still learning the
> > language - it was essentially a repeat loop and I replaced it in later
> > versions.
>
> Same here...
>
> But, I wonder. With modern optimizing compilers doing almost what they
> want with the original source code, I'm quite sure some semantic
> optimiser will replace parts of codes by goto's anyway.
> So why would it
> ever be necessary to worry about optimising the source code with
> 'spaghetti' code, as we are shifting the responsability for optimising
> execution to the compiler writers anyway?
The answer is clearly yes. The reason is simple, a perfect compiler does
not exist, you can prove that for each compiler, there exists a better
compiler. This is not pure theory, situations where the compiler
doesn't make the ideal decision are very common. Of course, if a modern
compiler isn't good enough, your code must be extremely speed critical, so
assembler code might be the best option
(which is full of jumps=goto).
However, assembler coded is not portable. A hand optimized Pascal
based solution with goto statements might be preferable over assembler
code. For example, in the file rtl/unix/video.pp , the procedure
update_vcsa uses a goto for speed reasons.
There are a few other situations you might run into where a goto can be
more practical than a goto-less solution. For example, jumping out of
nested loops, or jumping in case of an error condition. It is always
possible to avoid goto, but there exist cases where using it can be a good
engineering decision.
> If fact, if the optimiser is good, spaghetti (goto-)programs and 'nice'
> code should generate the same executable anyway, shouldn't they?
No. A program which determines if two programs are the same cannot exist,
this is an uncomputable problem. Because of this, a compiler cannot
transform unoptimized code into the most ideal "spaghetti" form.
Actually, FPC makes good use of this knowledge. Unlike most compilers, FPC
doesn't convert high level constructions into gotos internally. This gives
the code generator more information to decide the right instructions to
generate, for example for loops generate different code than while loops,
because in the case of the for loops, the compiler knows more about the
loop termination criterium.
> So,
> doesn't it make sense to try and make the source as readable as possible?
If the question is wether you should for example use a while loop, or
emulate it with a goto, the answer is a loud and clear yes. Only in very
seldom situations you want to have more control over what exact code is
generated.
However, the situations were a goto is sometimes preferred is when
avoiding it needs extra variables or statements. In this case, it is
mostly a matter of taste wether the goto makes the code more readable.
To sum it up: Theoretically nobody needs goto. For each use of goto, it
can be replaced with a goto-less construction. For each case where
the goto is more efficient, you can write an optimization. And for each
situation where a high level construction looks worse than a goto-based
construction, one can design a high-level construction that makes the goto
obsolete.
Practically however, one has to deal with that compilers are not, will
not, and cannot be perfect, and in some situations, the goto-less solution
feels like a work-around.
> (Which is why I use Pascal in the first place - without gotos)
Well, no modern language is goto based :)
But... Pascal pioneered it, and it is nice to know that all modern
languages carry a Pascal legacy in them.
Daniël Mantione
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
