Hi !
I need your advice -- I want to find stable gpc version suitable for my needs..
I'm run Linux [2.4.6 as for now, and I plan to further upgrades :-)].
I need gpc to compile user programs, which would be likely developed under mics. environment, but generally under DOS with old borland pascal {They think that BP IDE is the best}. Programs are expected to be relatively small, and I don't think that anyone would use OO-extensions more that for few strings, it would at all.
Actually, BP compatibility is not REQUIRED, but would be nice. Are there any standards in Pascal like ISO C ??
Personally I don't program Pascal, so I can't judge which one is better.
What can you tell me about FPC? Is it worth looking ??
thank you for your opinion.
P.s.: If that's wrong list for that type of questions, I'm terrible sorry, could you please direct me to right source?
Looks like you are new to the list. So here it goes:
Under Linux, just grab the latest version released (under alpha directory on an ftp server, last betta is already WAY out of sync), usually it is pretty stable.Download also gcc source, then compile and install it yourself (!!! follow gcc compilation isntructions carefully, that is use --enable-languages=pascal for configure, etc.). Be sure to use corresponding gcc version (3.0 is released now, but this is not in gpc yet, so use 2.95.3). Also do not install gcc itself (limit it to pascal only as I indicated), even better yet recompile gcc and reinstall it afterwards - gpc will work fine. I had issues (could not compile kernel). As far as other systems go my understanding is that it is better to just grab binaries and leave compilation to specialists :-). (while under linux it is quite essention to compile it yourself - different distributions have different ideas about where to put system files).
As far as IDE goes you can use Rhide under dos (djpp) and linux. I did not use gpc under dos though, but under linux I find it easy to use nedit or cooledit for my needs. There is actually peng/xpeng editor, that very closely resembles BP IDE (search for any of theese on a freshmeat (www.freshmeat.net)). i BP compatibility: except newest features introduced in Delphy it is working nice. Few features require special compilation options, few are unimplemented on purpose. But all of them are the ones which your better not use anyway - gpc does it more clearly - it implements Extended Pascal standard. You should start reading info pages for gpc it is all described there. FPC: there was a discussion on this list and as I remember the word was that it is not implementing so many extended pascal features and is not very optimising. I did not try that one - for me compatibility with standard library and ease of linking with c, c++ is important. gpc is based on a gcc backend, so all its features are easily accessible (just write the wrapper or link directly!).
On Fri, 20 Jul 2001, Bohdan Vlasyuk wrote:
Hi !
I need your advice -- I want to find stable gpc version suitable for my needs..
Actually, BP compatibility is not REQUIRED, but would be nice. Are there any standards in Pascal like ISO C ??
Personally I don't program Pascal, so I can't judge which one is better.
What can you tell me about FPC? Is it worth looking ??
thank you for your opinion.
[skipped]
George Shapovalov wrote:
There is actually peng/xpeng editor, that very closely resembles BP IDE (search for any of theese on a freshmeat (www.freshmeat.net)).
Don't think you'll find PENG there, it's not free (yet). It's at http://fjf.gnu.de/peng/
Frank
BP compatibility: except newest features introduced in Delphy it is working nice. Few features require special compilation options, few are unimplemented on purpose. But all of them are the ones which your better not use anyway - gpc does it more clearly - it implements Extended Pascal standard. You should start reading info pages for gpc it is all described there.
FPC: there was a discussion on this list and as I remember the word was that it is not implementing so many extended pascal features and is not
It doesn't even support standard Pascal. FPC is targeted at Borland Pascal and Delphi.
The development version (which is quite stable atm) nearly implements the entire Delphi syntax. (including Kylix and D6 extensions)
very optimising.
FPC is not as optimizing as GCC in extreme cases, but is generally something like -O without tail recursion, which is fine except for specific applications.
I did not try that one - for me compatibility with standard library and ease of linking with c, c++ is important.
FPC can link with c and C++.
gpc is based on a gcc backend, so all its features are easily accessible (just write the wrapper or link directly!).
FPC can do exactly the same, EXCEPT that it always requires Pascal headers.
FPC or GPC depends on your task and system. In general: - Non x86? Then GPC. (m68k FPC in beta) - Extended Pascal? -> GPC - Delphi code ? -> FPC
Marco van de Voort wrote:
I did not try that one - for me compatibility with standard library and ease of linking with c, c++ is important.
FPC can link with c and C++.
I think one main issue is type compatibility, i.e. can you be sure that, say `int' in C always matches `Integer' in Pascal in size -- otherwise (if that depends on the platform), translations of C headers would be bound to a particular platform.
FPC or GPC depends on your task and system. In general:
- Non x86? Then GPC. (m68k FPC in beta)
So maybe this issue hasn't arisen yet for FPC, but if I'd translate a header now, I'd also want to know if I'll have to do it again on each platform ...
Frank
Marco van de Voort wrote:
I did not try that one - for me compatibility with standard library and ease of linking with c, c++ is important.
FPC can link with c and C++.
I think one main issue is type compatibility, i.e. can you be sure that, say `int' in C always matches `Integer' in Pascal in size --
I don't see why this would have be like that. I already use special identifiers (like Cint Clong etc) in all my headers for a decade, from my M2 times.
I include a ctypes.inc in each header file. Till now this is not standard (I have to implement that file for each platform, but if FPC starts to support 64-bits processors, it could be supplied with each target, we are talking about plusminus 6-10 types here)
Pascal's typing will save you from errors, as long as you are consequent. Side benefit of this is that you can use a different programming model if desired. (e.g. if you major use is to interface with an application/system that uses a different convention than C/GCC). So you can be LP64 in an ILP64 world.
If you map 1:1 you are stuck with what C does, even it is difficult.
otherwise (if that depends on the platform), translations of C headers would be bound to a particular platform.
Or would need a 5 minute global replace before work can really start? As long as I'm consequent (translate C-int with longint etc) I can reverse the process.
FPC or GPC depends on your task and system. In general:
- Non x86? Then GPC. (m68k FPC in beta)
So maybe this issue hasn't arisen yet for FPC,
It hasn't arisen directly, but we also read C faqs from time to time. I also know about endianess, alignment etc :-)
We have to implement a n-bit clean CG from scratch, and I'm sure we can handle such details in the RTL.
but if I'd translate a header now, I'd also want to know if I'll have to do it again on each platform ...
[evil mode on]
Hmm, substitutions are not necessary. FPC supports qualified identifiers.
{$ifdef 64bit} {not complete} type longint=System.int64; shortint=System.longint; int64=System.int128; {problem. int64 is used as "long long", but int64 as type could exist in C too) {$endif} [evil mode off]
I had the problem with int64 above already years ago under Modula- 2 (where "CARDINAL" is a base type, which also exists under C. I had a 16-bit M2 (M2-CARDINAL=16-bit), and interfaced to DJGPP written structures (CARDINAL=32-bit)
It is the reason why I keep C and Pascal types strictly apart, and prefix c types with "c" in headers. Typing saves the day again :_)
In general, 64-bit problems were not that bad as I expected. This is probably due to the average lower use of pointers (specially strings), and cleaner code in Pascal.
I think endianess and alignment causes much more problems (when porting old x86 codebases to other processors) long term than 64-bit problems, specially for people that need cross platform binary compability from time to time. How does GPC deal with that?
-
Bohdan Vlasyuk -
Frank Heckenbach -
George Shapovalov -
Marco van de Voort -
marcov＠stack.nl