Dear FreePascal adepts,

when I was younger (about seven years ago), I wrote several programs in Borland's Turbo Pascal version 7 (IIRC).

I then learned C and haven't looked much at Pascal ever since. However, I'm still fond of Pascal's clear syntax, so I would like to know more about its advantages.

I would be very grateful if you could answer the following questions, loosely based on the "Advantages" section of the FreePascal homepage.

1) "No Makefiles"
...and yet you ship a Makefile generator with FPC. Why?

2) "Pascal compilers are Fast with a big F [...]"
Why is that?

3) "Great integration with assembler"
Is being able to use Assembler easily inline really that much better as opposed to having the code in separate object files?

4) "Smartlinking"
Ah, I think you can have that one in C with some obscure linker flags, too.

5) Why use Pascal instead of Ada?

6) Can I have run-time range checking of arrays/strings and *still* use functions that accept arrays of any length?

Thank you so much in advance for helping me.

Leslie

You're project don't need them. But the fpc libraries are something very complex being build for different target from the same source, containing also informations how to install things, build releases etc.

But we're just getting rid of make :)

2) "Pascal compilers are Fast with a big F [...]" Why is that?

Module support, properly designed language.

3) "Great integration with assembler" Is being able to use Assembler easily inline really that much better as opposed to having the code in separate object files?

Yes, you don't need an external assembler. You can access parameters literally etc.

4) "Smartlinking" Ah, I think you can have that one in C with some obscure linker flags, too.

Not as easy as in pascal.

5) Why use Pascal instead of Ada?

Why Ada and not Pascal?

6) Can I have run-time range checking of arrays/strings and *still* use functions that accept arrays of any length?

Yes.

Patrick Leslie Polzer wrote

1) "No Makefiles" ...and yet you ship a Makefile generator with FPC. Why?

Because you cannot tell the compiler to compiler run time library, then itself with the rtl that was just compiled, then recompile the run time library with the newly compiled compiler, then itself with the newly compiled compiler etc. fpcmake is a tool developed for internal use, but everyone is free to use it. You don't strictly need it except in complex cases like the above, though.

2) "Pascal compilers are Fast with a big F [...]" Why is that?

Because you do not need a preprocessor pass, and compiled unit interfaces can be reused much more often than e.g. C pre-compiled headers because no external defines can influence them (and therefore you also need much less checking to see whether or not a unit needs to be recompiled).

3) "Great integration with assembler" Is being able to use Assembler easily inline really that much better as opposed to having the code in separate object files?

Personal preference.

4) "Smartlinking" Ah, I think you can have that one in C with some obscure linker flags, too.

Nowadays you can indeed, yes.

5) Why use Pascal instead of Ada?

Personal preference.

6) Can I have run-time range checking of arrays/strings and *still* use functions that accept arrays of any length?

Yes.

Jonas

Op Tue, 20 Feb 2007, schreef Patrick Leslie Polzer:

Please try it. There is no better way to learn about its advantages than actual programming. This can better explain it to you than I can do in 1000 words. For many C programmers, getting into Free Pascal is a very enjoyable experience.

Since the compiler is able to find the dependencies of files automatically, do this is not something you need a Makefile for. However, there are several other things, like creating a tar or zip of your program, installing it and some more things. A makefile is one way to provide this functionality, which we make easy and user friendly by providing a makefile generator.

Still we are going to kick fpcmake, since makefiles are hard to port. As C programmer you probably know this, to be able to execute a configure script on Windows you need an Unix emulator like Cygwin or Msys.

Building the compiler using fpcmake on Windows requires people to several Unix utilities, like cp, mv. In near the future we will move to a build tool which doesn't depend on external tools to copy files etc., increasing the portability of the compiler.

2) "Pascal compilers are Fast with a big F [...]" Why is that?

The main reason for this is the unit system. If a C program uses a library, all header files need to be loaded and parsed, for each source file again. A Pascal compiler can simply load a unit from disk, so it doesn't need to parse headers. Further, once loaded, the unit remains in memory, so if the next file is compiled, it is ready to be used again.

Some C-compilers provide pre-compiled headers to provide some of the same advantages, but since the content of a header can change with a simple define, this is limited; until now this has not been very successfull in obtaining similar performance to Pascal compilers.

3) "Great integration with assembler" Is being able to use Assembler easily inline really that much better as opposed to having the code in separate object files?

Assembler at the Pascal level frees you from the trouble to access parameters. If you would write pure assembler you need to work with offsets on the stack that need to match what the compiler uses. This is very error prone.

Further, you can access any Pascal symbol directly from your assembler routines, which saves you all kinds of cubersome imports in your assembler files.

4) "Smartlinking" Ah, I think you can have that one in C with some obscure linker flags, too.

Recently it has become possible to do real smartlinking with gcc. FPC has done this since the late 90's; while gcc could only remove unused files, FPC could remove individual variables and procedures.

Still, it works better. Try to statically link a hello world in C and then smartlink a hello word in FPC. Compare the executables.

5) Why use Pascal instead of Ada?

Ada is a good language. Pascal is good language too, and modern Object Pascal might be even more advanced than Ada. For certain is that Pascal has better development tools, a much larger treasury chest of existing code and libraries and is much better documented due to the libraries of book been written on it.

6) Can I have run-time range checking of arrays/strings and *still* use functions that accept arrays of any length?

Yes. We call this open arrays.

Thank you so much in advance for helping me.

You're welcome :)

Daniël Mantione

Also FPC uses it more as a script to get actions done in an order. (make being one single .exe, small and easy to install), So in other words make with FPC is a bit less about laying out how to build an .exe/library, and a bit more to specify which exe's/libraries should be built.

(Personally I think one probably could get an enormous way with precompiled headers, specially _IF_ the headers are not to murky. But it requires a great lot of extra work on the compiler side, and is much less comprehendable for end users than the more well defined Pascal system. The fact that gcc doesn't have a precompiled header system yet after 20 years of development says enough I think)

Pro: integration between pascal code and assembler is much tighter. Even GCC resorts to a form of inline assembler, just less readable and userfriendly.

Con: people might inadvertedly use assembler when not necessary. THis is clearly visible in Delphi and TP source. OTOH in practice I don't think that this is such a big problem anymore with Delphi srcs, since people already have become more reluctant to use assembler. A minor annoyance when porting delphi sources. But in TP times it was _bad_.

I'm not entirely sure if the granularity is the same.

> 5) Why use Pascal instead of Ada? Personal preference.

Ditto, and in my case : Ada seems overly complex for every day use to me. But if I ever develop something nuclear, I'll keep it in mind.

Since the advantages of pascal were being discussed I thought I'd mention some of the
things that make me choose C over pascal for some things.

I don't actually think of these as 'pascal sucks because x'. It's more of 'We need to add x'
It's more compiler than language based.

1. Inline functions. C supports a lot more here a lot of it comes from the #include
based architecture, to do the same thing to Pascal you'd need to store a lot more
in the compiled unit. There's work there for someone.

2. SIMD support. I really don't know if this is something that should be added to FPC or
not. If I knew that SIMD was here to stay I'd say definitely. The tricky bit is it should
be a way to system independently generate SIMD code for different Instruction sets and
to generate standard non SIMD implementations for targets that lack the instructions.
It would also be interesting to see if there would be optimization gains for the compiler
using some sort of SIMD support at the language level even generating non SIMD code.
Any extension would effectively be giving extra information to the compiler about what is
being done. That can't hurt can it?

3. Umm I dunno. Guess that's why I love Pascal :-)

Of course there's the template-ey thing but that's been done to death.

Op Fri, 23 Feb 2007, schreef Neil Graham:

We've got a inline procdir? Or are you referring to macros?

There exists a Vector Pascal compiler. They basically extend the language with features to do vector operations, allowing them to do ground-breaking performance. The Vector Pascal extenstions are under our consideration, however, we need the infrastructure in the compiler first. Until then, take a look at Vector Pascal itself.

Daniël Mantione

Daniël Mantione wrote

We've got a inline procdir? Or are you referring to macros?

inline has the potential to do the trick but it's harder than something from a #include based
system because with an include system the compiler actually gets to see the original code
and can do a lot more.

I do admit it appears I'm a bit behind the times since things have gotten better since last
I looked. The docs now say "As of version 2.0.2, inline works accross units." and
barring the typo that's a great improvement. Does it actually store object or source code for
use across units? Transferring the source across allows optimizations with the surrounding
code that may not otherwise be possible.

I was unaware of Vector pascal. Googling it is getting me broken links, not a good sign.

Any idea if it's possible to share units between fpc and vector pascal?

Op Fri, 23 Feb 2007, schreef Neil Graham:

Tree nodes. This is a machine representation of the Pascal source.

Transferring the source across allows optimizations with the surrounding code that may not otherwise be possible.

Indeed, more and more inline optimizations become possible nowadays.

The site seems down indeed. I'd try again within a while.

Any idea if it's possible to share units between fpc and vector pascal?

Vector Pascal is a compiler that does not focus on Borland compatibility. It does implement the critical Borland features though (like units). So, if you limit yourself to use basic language features, code exchange might be feasible.

Daniël