Greetings from a new member of your mailing list.
I have used Gnu Pascal for some time on a Windows 10 64-bit environment.
I decided to try it on a Linux Mint 20 Cinnamon machine with x86_64 processor I downloaded gpc-2.1-with-gcc.i686-pc-linux-gnu.tar.gz to /home/peter/software and installed using:
cd / tar xzf /home/peter/software/gpc-2.1-with-gcc.i686-pc-linux-gnu.tar.gz
I tried the simplest of programs: Hello.c: program hello; begin writeln ('Hello Pascal world'); readln end. and compiled by gpc -o Hello Hello.pas to get, to my dismay, not as on Windows but on Linux: peter@peter-Akoya-E6237:~/Pete/Pascal$ gpc -o Hello Hello.pas /tmp/ccnPqfBD.s: Assembler messages: /tmp/ccnPqfBD.s:15: Error: invalid instruction suffix for `push' /tmp/ccnPqfBD.s:19: Error: invalid instruction suffix for `push' /tmp/ccnPqfBD.s:20: Error: invalid instruction suffix for `push' /tmp/ccnPqfBD.s:21: Error: invalid instruction suffix for `push' /tmp/ccnPqfBD.s:22: Error: invalid instruction suffix for `push' /tmp/ccnPqfBD.s:23: Error: invalid instruction suffix for `push' /tmp/ccnPqfBD.s:24: Error: invalid instruction suffix for `push' /tmp/ccnPqfBD.s:25: Error: invalid instruction suffix for `push' /tmp/ccnPqfBD.s:35: Error: invalid instruction suffix for `push' /tmp/ccnPqfBD.s:36: Error: invalid instruction suffix for `push' /tmp/ccnPqfBD.s:37: Error: invalid instruction suffix for `push' /tmp/ccnPqfBD.s:38: Error: invalid instruction suffix for `push' /tmp/ccnPqfBD.s:50: Error: invalid instruction suffix for `pop' /tmp/ccnPqfBD.s:66: Error: invalid instruction suffix for `push' /tmp/ccnPqfBD.s:73: Error: invalid instruction suffix for `push' /tmp/ccnPqfBD.s:80: Error: invalid instruction suffix for `pop' /tmp/ccnPqfBD.s:88: Error: invalid instruction suffix for `push' /tmp/ccnPqfBD.s:92: Error: invalid instruction suffix for `pop' /tmp/ccnPqfBD.s:103: Error: invalid instruction suffix for `push' /tmp/ccnPqfBD.s:108: Error: invalid instruction suffix for `push' /tmp/ccnPqfBD.s:110: Error: invalid instruction suffix for `push' /tmp/ccnPqfBD.s:112: Error: invalid instruction suffix for `push' /tmp/ccnPqfBD.s:123: Error: invalid instruction suffix for `pop' peter@peter-Akoya-E6237:~/Pete/Pascal$
What am I doing wrong? Can you please advise?
On 11/09/2020 12:09, Peter Williams wrote:
I decided to try it on a Linux Mint 20 Cinnamon machine with x86_64 processor I downloaded gpc-2.1-with-gcc.i686-pc-linux-gnu.tar.gz to  /home/peter/software and installed using:
That is a rather old version. Try https://launchpad.net/~ueter/+archive/ubuntu/gpc-3.4/+files/gpc-3.4_20070904...
For the GPC authors
So this could be considered either a proposal or a question, your choice.
Recently, for various reasons I have been studying the LLVM project (mainly because I am now forced to use LLVM on the Mac OS X). As I am sure you know, LLVM is becoming popular as a backend. For example, I believe FPC now uses it.
An interesting thing about LLVM is that they bent over backwards to make sure it was as compatible as possible with previous GCC methods, components and front-ends, with an eye to making it easy to port existing front ends to LLVM.
So I think you can guess where I am going with this. The GPC group dropped the GPC project mainly because GCC had changed and the requirements to meet the new GCC backend were too large to meet for the GPC group (WRT: Quo vas GPC).
Might that have changed with the introduction of LLVM? It would seem that the GPC front end would be a perfect match for LLVM, and the problems with upgrading to the current GCC backend may be solved with using LLVM as backend?
I looked at porting one of my compilers to LLVM, and decided that it would be more of a complete translation to meet the requirements of the LLVM intermediate format. Its a good/very good IR, but it has its own ideas about stack framing, calling conventions, etc. It would need a front end rewrite specifically to target that IR.
However, GPC, combined with the support LLVM provides for GCC legacy front ends, might be a different story.
A discussion, perhaps?
Scott Franco.
On 02/11/2020 21:32, scott andrew franco wrote:
For the GPC authors  So this could be considered either a proposal or a question, your choice.  Recently, for various reasons I have been studying the LLVM project (mainly because I am now forced to use LLVM on the Mac OS X). As I am sure you know, LLVM is becoming popular as a backend. For example, I believe FPC now uses it.
FPC supports it as an optional backend, and it will always be optional for the reasons outlined in https://wiki.freepascal.org/LLVM#Frequently_Asked_Questions
An interesting thing about LLVM is that they bent over backwards to make sure it was as compatible as possible with previous GCC methods, components and front-ends, with an eye to making it easy to port existing front ends to LLVM.
I'm only aware of the the DragonEgg project (https://dragonegg.llvm.org/) in the context, but that one hasn't been updated since LLVM 3.3 (June 2013). I'm not aware of it being easy in any way to port GCC frontents to LLVM.
There was llvm-gcc before that, but that was even more of a pain to maintain afaik.
Jonas
So much for the second coming of Unicode, eh? [1]
[1] to get this joke, you have to be both old and have studied documents that were old when you are young, ie., about the 1960's. Hint: Unicode (the character set) stole the name of something else...
--------- Original Message --------- Subject: Re: Proposal/question for GPC From: "Jonas Maebe" jonas@freepascal.org Date: 11/2/20 1:04 pm To: "gpc@gnu.de" gpc@gnu.de
On 02/11/2020 21:32, scott andrew franco wrote:
For the GPC authors
So this could be considered either a proposal or a question, your choice.
Recently, for various reasons I have been studying the LLVM project (mainly because I am now forced to use LLVM on the Mac OS X). As I am sure you know, LLVM is becoming popular as a backend. For example, I believe FPC now uses it.
FPC supports it as an optional backend, and it will always be optional for the reasons outlined in https://wiki.freepascal.org/LLVM#Frequently_Asked_Questions
An interesting thing about LLVM is that they bent over backwards to make sure it was as compatible as possible with previous GCC methods, components and front-ends, with an eye to making it easy to port existing front ends to LLVM.
I'm only aware of the the DragonEgg project (https://dragonegg.llvm.org/) in the context, but that one hasn't been updated since LLVM 3.3 (June 2013). I'm not aware of it being easy in any way to port GCC frontents to LLVM.
There was llvm-gcc before that, but that was even more of a pain to maintain afaik.
Jonas
_______________________________________________ Gpc mailing list Gpc@gnu.de https://www.g-n-u.de/mailman/listinfo/gpc
Mmm, I should add a PS: I align with the FPC group in that I like writing backends, so don't think LLVM would stop me from writing them in any case.
--------- Original Message --------- Subject: RE: Re: Proposal/question for GPC From: "scott andrew franco" samiam@moorecad.com Date: 11/2/20 1:25 pm To: "Jonas Maebe" jonas@freepascal.org, "gpc@gnu.de" gpc@gnu.de
So much for the second coming of Unicode, eh? [1]
[1] to get this joke, you have to be both old and have studied documents that were old when you are young, ie., about the 1960's. Hint: Unicode (the character set) stole the name of something else...
--------- Original Message --------- Subject: Re: Proposal/question for GPC From: "Jonas Maebe" jonas@freepascal.org Date: 11/2/20 1:04 pm To: "gpc@gnu.de" gpc@gnu.de
On 02/11/2020 21:32, scott andrew franco wrote:
For the GPC authors
So this could be considered either a proposal or a question, your choice.
Recently, for various reasons I have been studying the LLVM project (mainly because I am now forced to use LLVM on the Mac OS X). As I am sure you know, LLVM is becoming popular as a backend. For example, I believe FPC now uses it.
FPC supports it as an optional backend, and it will always be optional for the reasons outlined in https://wiki.freepascal.org/LLVM#Frequently_Asked_Questions
An interesting thing about LLVM is that they bent over backwards to make sure it was as compatible as possible with previous GCC methods, components and front-ends, with an eye to making it easy to port existing front ends to LLVM.
I'm only aware of the the DragonEgg project (https://dragonegg.llvm.org/) in the context, but that one hasn't been updated since LLVM 3.3 (June 2013). I'm not aware of it being easy in any way to port GCC frontents to LLVM.
There was llvm-gcc before that, but that was even more of a pain to maintain afaik.
Jonas
_______________________________________________ Gpc mailing list Gpc@gnu.de https://www.g-n-u.de/mailman/listinfo/gpc
On Mon, Nov 02, 2020 at 01:32:52PM -0700, scott andrew franco wrote:
For the GPC authors
So this could be considered either a proposal or a question, your choice.
Recently, for various reasons I have been studying the LLVM project (mainly because I am now forced to use LLVM on the Mac OS X). As I am sure you know, LLVM is becoming popular as a backend. For example, I believe FPC now uses it.
An interesting thing about LLVM is that they bent over backwards to make sure it was as compatible as possible with previous GCC methods, components and front-ends, with an eye to making it easy to port existing front ends to LLVM.
Actually, LLVM started as alternative optimizer for gcc. IIUC it never had all features needed for various gcc frontends. Currently compatibility features with gcc frontends seem to be phased out (or gone). IIUC Jonas wrote the same...
So I think you can guess where I am going with this. The GPC group dropped the GPC project mainly because GCC had changed and the requirements to meet the new GCC backend were too large to meet for the GPC group (WRT: Quo vas GPC).
That is simplified point of view. At least for me it was a set of reasons. More accurate statement would be that I decided to pursue another projects instead of adapting GPC to new backends. Put it differently: for me gain/effort ratio was too small. And let me remark that old backends work for me (with rather crude patch for contemporary Debian).
Might that have changed with the introduction of LLVM? It would seem that the GPC front end would be a perfect match for LLVM, and the problems with upgrading to the current GCC backend may be solved with using LLVM as backend?
In case I did not mention this earlier: one of my students used LLVM as a backend for compiler project. In about 2-3 years his compiler was broken by changes to LLVM and he gave up.
Thanks for the answers!
Scott Franco
--------- Original Message --------- Subject: Re: Proposal/question for GPC From: "Waldek Hebisch" hebisch@math.uni.wroc.pl Date: 11/3/20 10:32 am To: "gpc@gnu.de" gpc@gnu.de
On Mon, Nov 02, 2020 at 01:32:52PM -0700, scott andrew franco wrote:
For the GPC authors
So this could be considered either a proposal or a question, your choice.
Recently, for various reasons I have been studying the LLVM project (mainly because I am now forced to use LLVM on the Mac OS X). As I am sure you know, LLVM is becoming popular as a backend. For example, I believe FPC now uses it.
An interesting thing about LLVM is that they bent over backwards to make sure it was as compatible as possible with previous GCC methods, components and front-ends, with an eye to making it easy to port existing front ends to LLVM.
Actually, LLVM started as alternative optimizer for gcc. IIUC it never had all features needed for various gcc frontends. Currently compatibility features with gcc frontends seem to be phased out (or gone). IIUC Jonas wrote the same...
So I think you can guess where I am going with this. The GPC group dropped the GPC project mainly because GCC had changed and the requirements to meet the new GCC backend were too large to meet for the GPC group (WRT: Quo vas GPC).
That is simplified point of view. At least for me it was a set of reasons. More accurate statement would be that I decided to pursue another projects instead of adapting GPC to new backends. Put it differently: for me gain/effort ratio was too small. And let me remark that old backends work for me (with rather crude patch for contemporary Debian).
Might that have changed with the introduction of LLVM? It would seem that the GPC front end would be a perfect match for LLVM, and the problems with upgrading to the current GCC backend may be solved with using LLVM as backend?
In case I did not mention this earlier: one of my students used LLVM as a backend for compiler project. In about 2-3 years his compiler was broken by changes to LLVM and he gave up.
-- Waldek Hebisch
_______________________________________________ Gpc mailing list Gpc@gnu.de https://www.g-n-u.de/mailman/listinfo/gpc
-
Jonas Maebe -
Martin Liddle -
Peter Williams -
scott andrew franco -
Waldek Hebisch