[fpc-pascal] even linus torvalds prefer pascal over c

Daniël Mantione daniel.mantione at freepascal.org
Sat Dec 2 19:39:34 CET 2006



Op Sat, 2 Dec 2006, schreef John Coppens:

> On Sat, 02 Dec 2006 08:01:04 -0500
> David Mears <david.mears at suddenlink.net> 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=3Dgoto).

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=EBl Mantione


More information about the fpc-pascal mailing list