Dear GPC Collaborators,
PROBLEM: MacOS 10.15 does not run 32-bit binaries. My application uses 30k lines of GPC code. The MacOS GPC is 32-bit only.
MY FAILURE ON MACOS: The current GPC is compatible with the back-end of GCC 3.4.6 only. The procedure on all platforms is to compile gcc3.4.6 with the GPC sources. With a variety of C-compilers on MacOS (CLANG, GCC-4.9, GCC-5, and GCC-8), I can produce the two cross-compiler executables xgcc and xgpc. These are x86_64 executables. They both compile "Hello World", but they produce only 32-bit objects. When I pass "-m64", they say "Sorry: 64-bit not compiled in". I try building GCC 3.4.6 alone with:
config --target=x86_64-apple-darwin make
But I get, "Configuration x86_64-apple-darwin16.7.0 not supported". When I apply the same procedure to the GCC 4.9.4 sources, the build proceeds. The GCC 3.4.6 sources support 64-bit targets on Linux, so I was hoping it could do the same on MacOS. I have examined the GCC literature and the contents of gcc/config, but I still don't know what file should be present to provide x86_64 support on apple-darwin. Unless someone tells me otherwise, I'm going to assume that getting the 64-bit MacOS GPC out of GCC 3.4.6 is impossible.
Translating all my beautiful, reliable GPC code into another language does not sound like fun. Porting GPC to a newer version of GCC, such as GCC 8, is a possibility, but I understand that the GCC back-end team has a history of being uncooperative with the GPC team. Another solution is to port GPC to LVVM so we can use the CLANG compilers. The LVVM strategy seem like a good one to me: produce platform-independent code that then gets compiled and assembled. If I understand correctly, a CLANG front-end will work on any platform.
I would like to hear your advice. I have to solve this problem. I have allocated one thousand hours of my time to get it done. If there is a way to revive GPC with that amount of labor, I'll do it.
Best, Kevan
Kevan:
I wish you luck. I've had to give up on GPC because it fails to compile on MacOS. I think this neglect means that GPC is going to go defunct on all platforms. In contrast, the community of the Free Pascal Compiler (FPC) is alive but I still can't compile there. I can offer you translation to C: https://alum.mit.edu/www/toms/pascalp2c.html Unfortunately it does not do syntax checking and so can produce bad binaries. I currently use FPC to check syntax and if that works, then translate and compile in C.
Tom
Thomas D. Schneider, Ph.D. Senior Investigator National Institutes of Health National Cancer Institute Center for Cancer Research RNA Biology Laboratory Biological Information Theory Group Frederick, Maryland 21702-1201 schneidt@mail.nih.gov https://alum.mit.edu/www/toms
Tom,
In contrast, the community of the Free Pascal Compiler (FPC) is alive but I still can't compile there.
That's encouraging, that they are active, but in the long run, will they remain so? I'd be betting on them continuing. If I port GPC, I take control of it myself and I can make sure it keeps going. Kevan
Am 08.05.2020 um 00:50 schrieb Kevan Hashemi:
Tom,
In contrast, the community of the Free Pascal Compiler (FPC) is alive but I still can't compile there.
The offer in supporting people to get missing pieces of extended pascal (FPC's ISO support should be pretty complete) supported in FPC is still valid. But so far only a few tests are produced.
That's encouraging, that they are active, but in the long run, will they remain so?
This depends on you. FPC is not they. Every pascal programmer can contribute its share.
I'd be betting on them continuing. If I port GPC, I take control of it myself and I can make sure it keeps going.
All FPC sources are OSS and written in pascal, so you can always continue on adapting it. Of course, you can try again to keep the pace of GCC/LLVM and getting behind again. It's almost 30 years ago (wow, that long) that I decided that a GCC pascal frontend is not the way to go but a pascal compiler in pascal. I am still convinced this is the right approach :)
Dear Florian,
It is an honor to hear from you.
The offer in supporting people to get missing pieces of extended pascal (FPC's ISO support should be pretty complete) supported in FPC is still valid.
That is a generous offer.
But so far only a few tests are produced.
Is there an official format for a test? I'm happy to provide test code. Here is a test of GPC's schema types, of which I make heavy use.
{------------ A Test of Schema Types -----------} program p;
type image_type(j_size,i_size:integer)=record intensity:array [0..j_size-1,0..i_size-1] of integer; overlay:array [0..j_size-1,0..i_size-1] of integer; end; image_ptr_type=^image_type;
var ip:image_ptr_type; i,j,w:integer; begin writeln('Schema type test: an image array.'); write('Enter image width: '); readln(w); ip:=new(image_ptr_type,w,w); for i:=0 to w-1 do for j:=0 to w-1 do ip^.intensity[j,i]:=j*i; writeln('Test complete, final value ',j*i); end. {------------ End Test of Schema Types -----------}
All FPC sources are OSS and written in pascal
Really? Gosh. How could I have failed to know that FPC was written in Pascal? Maybe because it sounds too good to be true. Well, that's a significant development for my calculations.
I decided that a GCC pascal frontend is not the way to go but a pascal compiler in pascal.
You are making a compelling case. Instead of trying to re-write the GPC back-end, my time would be better spent working on the FPC front end so as to get my own code to compile. And I'd be working in Pascal, which would be a pleasure.
I am still convinced this is the right approach :)
I'm inclined to agree with you.
Best, Kevan
On 2020-05-07 5:11 p.m., Kevan Hashemi wrote:
Dear GPC Collaborators,
PROBLEM: MacOS 10.15 does not run 32-bit binaries. My application uses 30k lines of GPC code. The MacOS GPC is 32-bit only.
Hello Kevin,
Is there any other way?
Do you have no choice but to run 10.15?
Can you run in a virtual machine under 10.15?
Can you buy a 64 bit compiler for 10.15 and then find ways to get your code to compile by using workarounds for incompatibilities with GPC?
Regards,
Paul Isaacs
Dear Paul,
Is there any other way?
Yes, of course: translation, moving to FPC. But I am attracted to the idea of updating GPC.
Do you have no choice but to run 10.15?
There are hundreds of people using my software, and many of them, being academic, use MacOS. I just bought a new Mac, and I can't run my own software on it native.
Can you run in a virtual machine under 10.15?
Yes, but can't ask my users to do that.
Can you buy a 64 bit compiler for 10.15 and then find ways to get your code to compile by using workarounds for incompatibilities with GPC?
I had no idea there were commercial Pascal compilers out there. Can you point me to one?
Best, Kevan
On 2020-05-07 10:47 p.m., Kevan Hashemi wrote:
Dear Paul,
Is there any other way?
Yes, of course: translation, moving to FPC. But I am attracted to the idea of updating GPC.
Hello Kevan,
It was a faint hope on my part. No, I didn't find any commercial product for MacOS.
Might be best to try to tweak FPC for workarounds for GPC as the quickest thing to attempt first. A few days work should be enough to determine feasibility. In total there may not be that many differing workarounds required.
I don't think GCC would be easy to work on. It must be loaded with ifdef's and inscrutable macros given the number of platforms it supports and I wouldn't care to be coping with the RTL intermediate representation.
That doesn't include the changes that will be needed to GPC itself or any changes to the build makefiles.
Do your uses need source code? Would it be possible to distribute some kind of load and go VM 64 bit binary wrapper for your code?
Regards,
Paul
Dear Paul,
Might be best to try to tweak FPC for workarounds for GPC as the quickest thing to attempt first.
I am going to try translating a few things into FPC. My concern is not the time it would take to translate as the likelyhood of introducing bugs into the code.
My collaborators at the CERN lab in Geneva are analyzing 15000 images per hour in a cavern 100 m below the ground (ATLAS experiment, Large Hadronic Collider) 24 hours a day. They do not want to deal with the analysis code crashing on one image out of every million. Over there, I'm running the 64-bit version of GPC code on Linux machines. It's fast and stable. If I go to them and say "I'm giving the code a major overhaul so that it can be used on MacOS", they will not be pleased.
I don't want to touch the code itself.
I don't think GCC would be easy to work on.
I agree. And I don't like C. That's why I work in Pascal.
I wouldn't care to be coping with the RTL intermediate representation.
So far as I can tell, in GCC 4+ we don't have to deal with the register transfer language (RTL) at all. We have to take the tree generated by GPC and translate it into a GENERIC tree. We pass the GENERIC tree to the GCC middle-end, and the middle end translates it into a GIMPLE tree, optimises the code, translates it into RTL, and passes it to the back-end. The back-end matches the RTL to the machine definition and produces assembler code.
That doesn't include the changes that will be needed to GPC itself or any changes to the build makefiles.
The idea is to get GPC to produce a GENERIC tree.
Would it be possible to distribute some kind of load and go VM 64 bit binary wrapper for your code?
I did not know there was such a thing as a VM64 bit wrapper. Speak to me about this magical device, and I shall try it out immediately, for I need a short-term solution to the problem.
Best, Kevan
On Fri, May 08, 2020 at 09:52:56AM -0400, Kevan Hashemi wrote:
Dear Paul,
<snip>
I don't think GCC would be easy to work on.
I agree. And I don't like C. That's why I work in Pascal.
I wouldn't care to be coping with the RTL intermediate representation.
So far as I can tell, in GCC 4+ we don't have to deal with the register transfer language (RTL) at all. We have to take the tree generated by GPC and translate it into a GENERIC tree. We pass the GENERIC tree to the GCC middle-end, and the middle end translates it into a GIMPLE tree, optimises the code, translates it into RTL, and passes it to the back-end. The back-end matches the RTL to the machine definition and produces assembler code.
Right. And that is how support for GCC 4.x in current GPC works.
Would it be possible to distribute some kind of load and go VM 64 bit binary wrapper for your code?
I did not know there was such a thing as a VM64 bit wrapper. Speak to me about this magical device, and I shall try it out immediately, for I need a short-term solution to the problem.
I do not know what Paul meant, but there are things like docker. IIUC the idea is that you create "fat" application that contains inside enough of Linux to run your program. They provide a toolkit which is supposed to be easy to use and automate most of this. Never tried it so can not say how well it work. And when I say "like docker" I mean that I remember more than one proposal. I heard mostly about docker but possibly there is also something else with similar purpose.
Dear Kevan,
I know your pain. I am working to translate 500kloc of Extended Pascal to D for www.sarc.nl, for which I have written a transpiler (p2d). Our code has never compiled with GPC, we are probably the only one still using the commercial Prospero compiler. But p2d is not perfect, and it is a lot of work to prepare the code and test and debug the result. The result is not as pretty as we would like either, as some constructs (schematic arrays in particular) require verbose translations. Most bugs are due to clever low-level hacks in Pascal, that need special attention in the translation. I have currently spent more than double the time you have allocated to it, and now I have the first real program from our suite running (a tool for ship yards for preparing ship launches) including Windows GUI, printing, multi-threading, interfacing with 3rd party libraries etc. There is a lot of work ahead of me with many more programs to follow, but I'm confident that I'll get there.
We have considered GPC, FPC and Ada as well, but landed on D after a process described in [1]. The biggest change for our developers will be the C-like syntax, and the lack of native support for arrays with an index starting at something other than 0. This is compensated by a host of other features such as dynamic arrays, function overloading, generics, and much, much more -- without exposure to C++ (!). Feel free to contact me at Bastiaan@SARC.nl if you want to play with my transpiler or chat about the challenge, or D. (There is a very early version of p2d on GitHub, which I don't recommend using.)
I think your idea to port to LLVM is not bad, you won't be the only one using them as back-end. We would probably have ported to GPC if it had had a modern back-end two years ago. But be mindful of the fact that your code might not work on 64 bit right away. If you do pointer arithmetic, store pointers in integers, do binary file i/o, or rely on sizes of data types then you'll have to make those sections portable.
I am not sure if FPC supports MacOS 10.15. But if it does, you have one other option: Use GPC's parser to write a transpiler that outputs FPC-compatible code. This could be much easier than connecting GPC to LLVM, although retaining the comments and formatting might need extra attention. Thereafter you'll have the support of the FPC community, instead of being the sole expert on GPC...
Anyway, please do keep us informed.
[1] https://dlang.org/blog/2018/06/20/how-an-engineering-company-chose-to-migrat...
On 07/05/2020 23:11, Kevan Hashemi wrote:
Dear GPC Collaborators,
PROBLEM: MacOS 10.15 does not run 32-bit binaries. My application uses 30k lines of GPC code. The MacOS GPC is 32-bit only.
MY FAILURE ON MACOS: The current GPC is compatible with the back-end of GCC 3.4.6 only. The procedure on all platforms is to compile gcc3.4.6 with the GPC sources. With a variety of C-compilers on MacOS (CLANG, GCC-4.9, GCC-5, and GCC-8), I can produce the two cross-compiler executables xgcc and xgpc. These are x86_64 executables. They both compile "Hello World", but they produce only 32-bit objects. When I pass "-m64", they say "Sorry: 64-bit not compiled in". I try building GCC 3.4.6 alone with:
config --target=x86_64-apple-darwin make
But I get, "Configuration x86_64-apple-darwin16.7.0 not supported". When I apply the same procedure to the GCC 4.9.4 sources, the build proceeds. The GCC 3.4.6 sources support 64-bit targets on Linux, so I was hoping it could do the same on MacOS. I have examined the GCC literature and the contents of gcc/config, but I still don't know what file should be present to provide x86_64 support on apple-darwin. Unless someone tells me otherwise, I'm going to assume that getting the 64-bit MacOS GPC out of GCC 3.4.6 is impossible.
Translating all my beautiful, reliable GPC code into another language does not sound like fun. Porting GPC to a newer version of GCC, such as GCC 8, is a possibility, but I understand that the GCC back-end team has a history of being uncooperative with the GPC team. Another solution is to port GPC to LVVM so we can use the CLANG compilers. The LVVM strategy seem like a good one to me: produce platform-independent code that then gets compiled and assembled. If I understand correctly, a CLANG front-end will work on any platform.
I would like to hear your advice. I have to solve this problem. I have allocated one thousand hours of my time to get it done. If there is a way to revive GPC with that amount of labor, I'll do it.
Best, Kevan
On Thu, May 07, 2020 at 05:11:05PM -0400, Kevan Hashemi wrote:
Dear GPC Collaborators,
PROBLEM: MacOS 10.15 does not run 32-bit binaries. My application uses 30k lines of GPC code. The MacOS GPC is 32-bit only.
MY FAILURE ON MACOS: The current GPC is compatible with the back-end of GCC 3.4.6 only.
No. While little used GCC 4.1.2 port is finished and should work well.
The procedure on all platforms is to compile gcc3.4.6 with the GPC sources. With a variety of C-compilers on MacOS (CLANG, GCC-4.9, GCC-5, and GCC-8), I can produce the two cross-compiler executables xgcc and xgpc. These are x86_64 executables. They both compile "Hello World", but they produce only 32-bit objects. When I pass "-m64", they say "Sorry: 64-bit not compiled in". I try building GCC 3.4.6 alone with:
config --target=x86_64-apple-darwin make
But I get, "Configuration x86_64-apple-darwin16.7.0 not supported". When I apply the same procedure to the GCC 4.9.4 sources, the build proceeds. The GCC 3.4.6 sources support 64-bit targets on Linux, so I was hoping it could do the same on MacOS. I have examined the GCC literature and the contents of gcc/config, but I still don't know what file should be present to provide x86_64 support on apple-darwin. Unless someone tells me otherwise, I'm going to assume that getting the 64-bit MacOS GPC out of GCC 3.4.6 is impossible.
Translating all my beautiful, reliable GPC code into another language does not sound like fun. Porting GPC to a newer version of GCC, such as GCC 8, is a possibility, but I understand that the GCC back-end team has a history of being uncooperative with the GPC team. Another solution is to port GPC to LVVM so we can use the CLANG compilers. The LVVM strategy seem like a good one to me: produce platform-independent code that then gets compiled and assembled. If I understand correctly, a CLANG front-end will work on any platform.
I would like to hear your advice. I have to solve this problem. I have allocated one thousand hours of my time to get it done. If there is a way to revive GPC with that amount of labor, I'll do it.
First step would be to find out earliest GCC which supports 64-bit Mac OS as target. It is possible that GCC-4.3.5 will do, attempting to build gets beyond "Configuration x86_64-apple-darwin16.7.0 not supported" (full build requies Apple tools so I can not check if it works).
Anyway, I would suggenst trying
with GCC-4.3.5. Look at README, for 4.3.5 you need to use '--disable-mapped-location'.
On Fri, May 08, 2020 at 04:53:37PM +0200, Waldek Hebisch wrote:
On Thu, May 07, 2020 at 05:11:05PM -0400, Kevan Hashemi wrote:
Dear GPC Collaborators,
PROBLEM: MacOS 10.15 does not run 32-bit binaries. My application uses 30k lines of GPC code. The MacOS GPC is 32-bit only.
No. While little used GCC 4.1.2 port is finished and should work well.
For the record: with patches that I posted in reply to John Ries I am able to build GPC based on GCC 4.3.6 on Linux using clang version 7. So it should be possible to use clang for bootstrapping GPC on Mac without too much fiddling with compiler flags.
IIUC ATM there are other unresolved problems, but this is a step forward...
I hadn't thought of using clang. I'll give it a try.
John L. Ries 26215 197th Ave. SE Covington, WA 98042 (435) 867-8885
On Sat, May 16, 2020 at 5:32 PM Waldek Hebisch hebisch@math.uni.wroc.pl wrote:
On Fri, May 08, 2020 at 04:53:37PM +0200, Waldek Hebisch wrote:
On Thu, May 07, 2020 at 05:11:05PM -0400, Kevan Hashemi wrote:
Dear GPC Collaborators,
PROBLEM: MacOS 10.15 does not run 32-bit binaries. My application uses
30k lines of GPC code. The MacOS GPC is 32-bit only.
No. While little used GCC 4.1.2 port is finished and should work well.
For the record: with patches that I posted in reply to John Ries I am able to build GPC based on GCC 4.3.6 on Linux using clang version 7. So it should be possible to use clang for bootstrapping GPC on Mac without too much fiddling with compiler flags.
IIUC ATM there are other unresolved problems, but this is a step forward...
-- Waldek Hebisch
Gpc mailing list Gpc@gnu.de https://www.g-n-u.de/mailman/listinfo/gpc
Dear John,
I hadn't thought of using clang. I'll give it a try.
I have encountered only two problems with the clang compiler and linker.
(1) The won't compile assembler with .stabs, which means it won't compile the output of GCC3.4.6. No longer a problem when trying to compile GPC with GCC 4.3.6.
(2) The compiler ignores the -std=gnu89 flag, which is necessary to get around some gnu90 incompatibility errors I encountered on GPC 4.3.5.
Best, Kevan
I tried using sum2.diff, but it caused make to look for a non-existent object file, so it doesn't appear to be necessary under Fedora. I therefore backed it out. Thereon I rebuilt using the system GCC and searched for something under the built directory with a name resembling "libgpc.a". It doesn't exist.
$ find . -name "*gpc*" ./gcc/gpc1 ./gcc/xgpc ./gcc/gpc-run ./gcc/p/gpcpp.o ./gcc/p/gpc-lex.o ./gcc/p/gpc.o ./prev-gcc/gpc1 ./prev-gcc/xgpc ./prev-gcc/gpc-run ./prev-gcc/p/gpcpp.o ./prev-gcc/p/gpc-lex.o ./prev-gcc/p/gpc.o
So it looks like I get to give clang a shot.
On Sat, May 16, 2020 at 5:32 PM Waldek Hebisch hebisch@math.uni.wroc.pl wrote:
On Fri, May 08, 2020 at 04:53:37PM +0200, Waldek Hebisch wrote:
On Thu, May 07, 2020 at 05:11:05PM -0400, Kevan Hashemi wrote:
Dear GPC Collaborators,
PROBLEM: MacOS 10.15 does not run 32-bit binaries. My application uses
30k lines of GPC code. The MacOS GPC is 32-bit only.
No. While little used GCC 4.1.2 port is finished and should work well.
For the record: with patches that I posted in reply to John Ries I am able to build GPC based on GCC 4.3.6 on Linux using clang version 7. So it should be possible to use clang for bootstrapping GPC on Mac without too much fiddling with compiler flags.
IIUC ATM there are other unresolved problems, but this is a step forward...
-- Waldek Hebisch
Gpc mailing list Gpc@gnu.de https://www.g-n-u.de/mailman/listinfo/gpc
On Sun, May 17, 2020 at 01:41:01PM -0700, John Ries wrote:
I tried using sum2.diff, but it caused make to look for a non-existent object file, so it doesn't appear to be necessary under Fedora. I therefore backed it out. Thereon I rebuilt using the system GCC and searched for something under the built directory with a name resembling "libgpc.a". It doesn't exist.
$ find . -name "*gpc*" ./gcc/gpc1 ./gcc/xgpc ./gcc/gpc-run ./gcc/p/gpcpp.o ./gcc/p/gpc-lex.o ./gcc/p/gpc.o ./prev-gcc/gpc1 ./prev-gcc/xgpc ./prev-gcc/gpc-run ./prev-gcc/p/gpcpp.o ./prev-gcc/p/gpc-lex.o ./prev-gcc/p/gpc.o
So it looks like I get to give clang a shot.
clang is unlikely to change anything. First, check that you have correctly setup sources. When you look at gcc-4.x.x source tree you should see several libsomething subdirectories. For patched gcc in gcc-4.3.6.nn2 directory I see:
$ ../gcc-4.3.6.nn2
ABOUT-NLS README.SCO install-sh libtool-ldflags COPYING boehm-gc intl libtool.m4 COPYING.LIB compile libada ltgcc.m4 COPYING3 config libcpp ltmain.sh COPYING3.LIB config-ml.in libdecnumber ltoptions.m4 ChangeLog config.guess libffi ltsugar.m4 ChangeLog.tree-ssa config.rpath libgcc ltversion.m4 INSTALL config.sub libgfortran lt~obsolete.m4 LAST_UPDATED configure libgomp maintainer-scripts MAINTAINERS configure.ac libgpc missing MD5SUMS contrib libiberty mkdep Makefile.def depcomp libjava mkinstalldirs Makefile.in fixincludes libmudflap move-if-change Makefile.tpl gcc libobjc symlink-tree NEWS gnattools libssp ylwrap README include libstdc++-v3 zlib
Note 'libgpc' there. It is not present in gcc sources. README says:
: To build with gcc-4.y copy the libgpc subdirectory into toplevel gcc : directory (that is into gcc-4.y.z) and ...
If you forget this step, then 'libgpc' directory above will be missing and clearly there will be no way to make 'libgpc.a'.
OTOH if you followd the instruction and 'libgpc' is present, then we will have to examine messages coming from build (it is useful to redirect messages to a file so that one can look at them without re-running the build).
Thank you for confirming that clang doesn't change anything. I'll follow the directions above.
John L. Ries 26215 197th Ave. SE Covington, WA 98042 (435) 867-8885
On Sun, May 17, 2020 at 2:06 PM Waldek Hebisch hebisch@math.uni.wroc.pl wrote:
On Sun, May 17, 2020 at 01:41:01PM -0700, John Ries wrote:
I tried using sum2.diff, but it caused make to look for a non-existent object file, so it doesn't appear to be necessary under Fedora. I therefore backed it out. Thereon I rebuilt using the system GCC and searched for something under the built directory with a name resembling "libgpc.a". It doesn't exist.
$ find . -name "*gpc*" ./gcc/gpc1 ./gcc/xgpc ./gcc/gpc-run ./gcc/p/gpcpp.o ./gcc/p/gpc-lex.o ./gcc/p/gpc.o ./prev-gcc/gpc1 ./prev-gcc/xgpc ./prev-gcc/gpc-run ./prev-gcc/p/gpcpp.o ./prev-gcc/p/gpc-lex.o ./prev-gcc/p/gpc.o
So it looks like I get to give clang a shot.
clang is unlikely to change anything. First, check that you have correctly setup sources. When you look at gcc-4.x.x source tree you should see several libsomething subdirectories. For patched gcc in gcc-4.3.6.nn2 directory I see:
$ ../gcc-4.3.6.nn2
ABOUT-NLS README.SCO install-sh libtool-ldflags COPYING boehm-gc intl libtool.m4 COPYING.LIB compile libada ltgcc.m4 COPYING3 config libcpp ltmain.sh COPYING3.LIB config-ml.in libdecnumber ltoptions.m4 ChangeLog config.guess libffi ltsugar.m4 ChangeLog.tree-ssa config.rpath libgcc ltversion.m4 INSTALL config.sub libgfortran lt~obsolete.m4 LAST_UPDATED configure libgomp maintainer-scripts MAINTAINERS configure.ac libgpc missing MD5SUMS contrib libiberty mkdep Makefile.def depcomp libjava mkinstalldirs Makefile.in fixincludes libmudflap move-if-change Makefile.tpl gcc libobjc symlink-tree NEWS gnattools libssp ylwrap README include libstdc++-v3 zlib
Note 'libgpc' there. It is not present in gcc sources. README says:
: To build with gcc-4.y copy the libgpc subdirectory into toplevel gcc : directory (that is into gcc-4.y.z) and ...
If you forget this step, then 'libgpc' directory above will be missing and clearly there will be no way to make 'libgpc.a'.
OTOH if you followd the instruction and 'libgpc' is present, then we will have to examine messages coming from build (it is useful to redirect messages to a file so that one can look at them without re-running the build).
-- Waldek Hebisch
We have a solution. The problem was that I misread the directions and put the libgpc directory in the wrong place. However, I did have to hard copy it into the root of the gcc source directory tree instead of soft linking it due to confusion over parent directories. The README should be altered to reflect this reality.
SAV builds, so I'm happier. When I'm satisfied that it works, I'll be ready to try a Mac build.
John L. Ries 26215 197th Ave. SE Covington, WA 98042 (435) 867-8885
On Sun, May 17, 2020 at 9:54 PM John Ries john@theyarnbard.com wrote:
Thank you for confirming that clang doesn't change anything. I'll follow the directions above.
John L. Ries 26215 197th Ave. SE Covington, WA 98042 (435) 867-8885
On Sun, May 17, 2020 at 2:06 PM Waldek Hebisch hebisch@math.uni.wroc.pl wrote:
On Sun, May 17, 2020 at 01:41:01PM -0700, John Ries wrote:
I tried using sum2.diff, but it caused make to look for a non-existent object file, so it doesn't appear to be necessary under Fedora. I therefore backed it out. Thereon I rebuilt using the system GCC and searched for something under the built directory with a name resembling "libgpc.a". It doesn't exist.
$ find . -name "*gpc*" ./gcc/gpc1 ./gcc/xgpc ./gcc/gpc-run ./gcc/p/gpcpp.o ./gcc/p/gpc-lex.o ./gcc/p/gpc.o ./prev-gcc/gpc1 ./prev-gcc/xgpc ./prev-gcc/gpc-run ./prev-gcc/p/gpcpp.o ./prev-gcc/p/gpc-lex.o ./prev-gcc/p/gpc.o
So it looks like I get to give clang a shot.
clang is unlikely to change anything. First, check that you have correctly setup sources. When you look at gcc-4.x.x source tree you should see several libsomething subdirectories. For patched gcc in gcc-4.3.6.nn2 directory I see:
$ ../gcc-4.3.6.nn2
ABOUT-NLS README.SCO install-sh libtool-ldflags COPYING boehm-gc intl libtool.m4 COPYING.LIB compile libada ltgcc.m4 COPYING3 config libcpp ltmain.sh COPYING3.LIB config-ml.in libdecnumber ltoptions.m4 ChangeLog config.guess libffi ltsugar.m4 ChangeLog.tree-ssa config.rpath libgcc ltversion.m4 INSTALL config.sub libgfortran lt~obsolete.m4 LAST_UPDATED configure libgomp maintainer-scripts MAINTAINERS configure.ac libgpc missing MD5SUMS contrib libiberty mkdep Makefile.def depcomp libjava mkinstalldirs Makefile.in fixincludes libmudflap move-if-change Makefile.tpl gcc libobjc symlink-tree NEWS gnattools libssp ylwrap README include libstdc++-v3 zlib
Note 'libgpc' there. It is not present in gcc sources. README says:
: To build with gcc-4.y copy the libgpc subdirectory into toplevel gcc : directory (that is into gcc-4.y.z) and ...
If you forget this step, then 'libgpc' directory above will be missing and clearly there will be no way to make 'libgpc.a'.
OTOH if you followd the instruction and 'libgpc' is present, then we will have to examine messages coming from build (it is useful to redirect messages to a file so that one can look at them without re-running the build).
-- Waldek Hebisch
Dear All,
Through my own negligence, I allowed MacOS 10.15's rejection of 32-bit applications to catch my by surprise. I asked my users to give me four weeks to fix the problem. After one week I realised that my knowledge of GCC and GPC fell far short of what was required to get the 64-Bit compilation to work on MacOS. I spent a week figuring out if translation to FPC was possible, and having found that it was, I began translating. As of yesterday, I have my FPC code running 64-bit on MacOS, Linux, and Windows.
I wish you luck with the 64-bit compile on MacOS. I have enjoyed programming in GPC for fifteen years. Thanks to all those who created and maintained GPC. Thanks to all of you for the help you have given me on this list over the years.
Best, Kevan
Kevan:
I wish you luck with the 64-bit compile on MacOS. I have enjoyed programming in GPC for fifteen years. Thanks to all those who created and maintained GPC. Thanks to all of you for the help you have given me on this list over the years.
Thanks for your efforts on getting GPC going again on MacOS 64 bit.
May I suggest that you write up your knowledge of what you did? This could include what works, what doesn't work and what you think is needed to finish the job. This way perhaps others could pick up where you left off. It could be a posting on this mailing list.
Thanks,
Tom
Thomas D. Schneider, Ph.D. Senior Investigator National Institutes of Health National Cancer Institute Center for Cancer Research RNA Biology Laboratory Biological Information Theory Group Frederick, Maryland 21702-1201 schneidt@mail.nih.gov https://alum.mit.edu/www/toms
Dear Thomas,
May I suggest that you write up your knowledge of what you did?
Here is my GPC web page, which I'll leave up as it is.
http://www.bndhep.net/Software/Pascal/Pascal.html
Here are a few things that might prove useful, but which are already known to Waldek, Gale, and John.
(1) There is no port to MacOS of Binutils "as" and "ld". With MacOS Command Line Tools comes the CLANG C-compiler, assembler, and linker. There is also a GNU-like assembler, which you can get access to with "as -Q". This GNU-Like assembler is an Apple-created branch of the true GNU Assembler dating back two decades.
(2) The original GCC 3.4.6, which I hoped to use to compile GPC on MacOS, produces .stabs debug assembler directives. The CLANG assembler does not recognise .stabs directives. But the GNU-like assembler does recognise them.
(3) The GNU-like assembler will not accept certain movq x64_86 instructions generated by the host's GCC 4+ compiler, or the host CLANG CC compiler, when building the target GCC 3.4.6. But the CLANG assembler will accept these instructions.
Corrolary: In order to compile GCC 3.4.6, we need to start with the CLANG compiler to compile the XGCC, then switch to the GNU-Like assembler to assemble the output of XGCC as it compiles GPC. I was doing this by hand because I could not figure out how to get the configure or Makefiles to make the switch automatically.
(4) Having compiled an intermediate cross-compiler, XGCC 3.4.6, I can get most of the way to producing GPC, but only in 32-bit. So far as I can tell, GCC 3.4.6 does not support x86_64 on MacOS. So we have to compile GPC with a later GCC.
(5) Now Waldek provides a modified GPC that he is able to compile with GCC 4.3.5. I try that on MacOS. We need the "-std=gnu89" option during the compile of GCC 4.3.5, whcih the CLANG compiler does not recognise. So we must compile GCC 4.3.5 with another GCC compiler. I worked with GCC 4.9.4 and "-std=gnu89".
(6) At this point, I'm getting duplicate library routine errors, which I can get past by deleting object files. Waldek tells me there he suspects some confusion with the limits.h header files. I have 99 instances of this file on my machine. My machine is a mess.
That's it.
Best, Kevan
Kevan:
May I suggest that you write up your knowledge of what you did?
Here is my GPC web page, which I'll leave up as it is.
http://www.bndhep.net/Software/Pascal/Pascal.html
Here are a few things that might prove useful, but which are already known to Waldek, Gale, and John.
Thanks! At least now there is some record and maybe that will help the next person to work on this.
Tom
Thomas D. Schneider, Ph.D. Senior Investigator National Institutes of Health National Cancer Institute Center for Cancer Research RNA Biology Laboratory Biological Information Theory Group Frederick, Maryland 21702-1201 schneidt@mail.nih.gov https://alum.mit.edu/www/toms
Dear Tom,
At least now there is some record and maybe that will help the next person to work on this.
I'll add two more comments that explain why I gave up on the GNU Compiler Collection.
(7) Waldek has GPC compiling on GCC 4.3.5. As I describe in (5) and (6), I was unable to build GCC 4.3.5 on MacOS. But I do have GCC 4.9.4, installed by Home Brew. So I thought, "Surely I can just use 4.9.4, maybe a few tweaks will be required." But no, it's not just a few tweaks. Between GCC 4.3.5 and 4.9.4, the GCC people made dramatic changes to the interface between the front end and the middle end. The file varray.c is gone. The definition of the GENERIC tree structure is scattered through a bunch of new files and is incompatible with the old structures.
The GCC team claim their objective is to provide a platform upon which we can create front-ends for any and all languages we want. It's the "GNU Compiler Collection". It's a great idea. It's the idea that drew me into GPC and GCC in the first place. We can combine FORTRAN, Pascal, and C and link them into one executable. It was great.
http://www.bndhep.net/Software/Mixing/Mixing_Manual.html
But fundamental to any such endeavor is a firm commitment to backward compatibility. Making dramatic changes to the trees interface that break other people's front ends is absolutely contrary to the "compiler collection" philosophy. The GCC team has abandoned its mission. Maybe they have recovered their sense of direction in the past ten years, since GCC 4, heading into GCC 11, but I doubt it.
And that's when I gave up. I hate C, that's why I program in Pascal. Spending hundreds of hours programming in C to get a Pascal compiler to work was going to be painful. So I switched to FPC. And now I discover that the secondary problems with GCC (it's a pain in the neck) have been obscuring its primary problems.
(8) According to comments in the GPC source files, one of the reasons the GCC team goes ahead and breaks other people's front ends is because they are implementing new optimisation routines. So, we would expect the GCC code to be fast, even if GCC itself is a pain in the neck. But my FPC code runs approximately twice as fast as my GCC code. I tested it inverting 100 x 100 matrices on a Linux machine where I have both GPC and FPC running in 64-bit. Most compile-time optimisation takes place in the middle and back ends, not the front end. So, after all that fuss, and making so much work for Waldek and the rest of the GPC writers, the GCC crew still can't produce efficient code. And because GCC compiles itslef, the compiler itself is slow. Compiling my code with FPC goes twice as fast as compiling with GCC.
My conclusion is that GCC is a disorganised and ineffectual mess. The header and macro arrangement beloved of C has created a monstrous body of code that is almost impossible to compile and is being modified continuously by people who don't want to maintain the version they released six months ago, even though that version was dramatically different from the version they released a year ago. I note that MacOS abandoned GCC, switching to CLANG, and Windows does not appear to use GCC at all. Only on Linux is GCC common, but people are starting to build Linux with CLANG, so we'll see what the future holds for GCC. I'm not optimistic.
Best, Kevan
On Wed, Jun 03, 2020 at 09:03:44AM -0400, Kevan Hashemi wrote:
Dear Tom,
At least now there is some record and maybe that will help the next person to work on this.
I'll add two more comments that explain why I gave up on the GNU Compiler Collection.
(7) Waldek has GPC compiling on GCC 4.3.5. As I describe in (5) and (6), I was unable to build GCC 4.3.5 on MacOS. But I do have GCC 4.9.4, installed by Home Brew. So I thought, "Surely I can just use 4.9.4, maybe a few tweaks will be required." But no, it's not just a few tweaks. Between GCC 4.3.5 and 4.9.4, the GCC people made dramatic changes to the interface between the front end and the middle end. The file varray.c is gone. The definition of the GENERIC tree structure is scattered through a bunch of new files and is incompatible with the old structures.
My past experience was that I needed about month of work to update to new GCC version (say 4.1 to 4.2). Skipping intermediate versions can save some work. OTOH, since changes are larger more effort goes into finding new way of doing things.
The GCC team claim their objective is to provide a platform upon which we can create front-ends for any and all languages we want. It's the "GNU Compiler Collection". It's a great idea. It's the idea that drew me into GPC and GCC in the first place. We can combine FORTRAN, Pascal, and C and link them into one executable. It was great.
http://www.bndhep.net/Software/Mixing/Mixing_Manual.html
But fundamental to any such endeavor is a firm commitment to backward compatibility. Making dramatic changes to the trees interface that break other people's front ends is absolutely contrary to the "compiler collection" philosophy. The GCC team has abandoned its mission. Maybe they have recovered their sense of direction in the past ten years, since GCC 4, heading into GCC 11, but I doubt it.
Yes. There is "Run with us or get lost" attiude in GCC comunity. Just to keep front end in sync with backend requires substantial work.
And that's when I gave up. I hate C, that's why I program in Pascal. Spending hundreds of hours programming in C to get a Pascal compiler to work was going to be painful.
Sure, understand.
So I switched to FPC. And now I discover that the secondary problems with GCC (it's a pain in the neck) have been obscuring its primary problems.
(8) According to comments in the GPC source files, one of the reasons the GCC team goes ahead and breaks other people's front ends is because they are implementing new optimisation routines. So, we would expect the GCC code to be fast, even if GCC itself is a pain in the neck. But my FPC code runs approximately twice as fast as my GCC code. I tested it inverting 100 x 100 matrices on a Linux machine where I have both GPC and FPC running in 64-bit.
Could you post your benchmark. To say the truth I spent some time looking at assembly code produced by GPC and cases when it was possible to gain significant speedup at assembly level were quite rare. What I have seen were: - tiny routines (especially tiny loops) have kind of random speed, adding useless instrution can make tiny look go faster, moving code to different place in memory can change runtime - Pascal semantics sometimes forces less efficient code. In particular Pascal requires "correct" handling of edge cases and code needed for this may increase runtime - bit-packed arrays are particularly inefficient. Decision to implement bit-packing in GNU Pascal was long ago and probably was a mistake. Here most of blame is on front end, AFAIK GNU Pascal is the only Pascal compiler that implements bit-packing. Theoretically back end could do better job with bit-packing, but it is hard to blame GCC folks that they do not optimize code that almost nobody uses.
Most compile-time optimisation takes place in the middle and back ends, not the front end. So, after all that fuss, and making so much work for Waldek and the rest of the GPC writers, the GCC crew still can't produce efficient code. And because GCC compiles itslef, the compiler itself is slow. Compiling my code with FPC goes twice as fast as compiling with GCC.
My conclusion is that GCC is a disorganised and ineffectual mess. The header and macro arrangement beloved of C has created a monstrous body of code that is almost impossible to compile and is being modified continuously by people who don't want to maintain the version they released six months ago, even though that version was dramatically different from the version they released a year ago. I note that MacOS abandoned GCC, switching to CLANG, and Windows does not appear to use GCC at all. Only on Linux is GCC common, but people are starting to build Linux with CLANG, so we'll see what the future holds for GCC. I'm not optimistic.
Well, Aplle decided to use LLVM mostly for licencing reasons: they want to control software on iPhones (so that it is Apple who controls what gets installed on users iPhone), and GPL 3 (used for GCC 4.2 and higher) requires that users have ability to install their own programs.
LLVM is a fresh start, so it was cleaner due to lack of of old warts. Now LLVM has accumulated its own warts and partially in response to LLVM GCC folks have done large cleanups. And one effect of GCC cleanups is that old interfaces used by GPC got replaced by different ones making GPC porting harder...
BTW. My student made a small compiler interfacing LLVM (he did not want to deal with GCC). In about 2 years his compiler got completely broken by changes to LLVM interface...
Dear Waldek,
My past experience was that I needed about month of work to update to new GCC version (say 4.1 to 4.2).
I'm looking at this list of releases:
https://www.gnu.org/software/gcc/releases.html
Looks as if you would have to spend half your time working on this just to keep up.
Could you post your benchmark.
I'll prepare a stand-alone Pascal console program that inverts matrices populated with random numbers, and can be compiled in FPC and GPC by use of a compiler directive. The code won't be exactly the same: on GPC I used dynamic schema for the matrices, and on FPC I use dynamic arrays. I will then send the code as an attachment to the list with some benchmark measurements in the comments. This effort will have to wait a week or two, because I have dropped behind schedule with other stuff, and Brandeis University campus is opening up at last. But I will do it.
- tiny routines (especially tiny loops) have kind of random speed,
adding useless instrution can make tiny look go faster, moving code to different place in memory can change runtime
Interesting. The matrix inverter is not a tiny loop. It is subtracting matrix rows and replacing matrix rows with new rows. So it's a lot of real number arithmetic and conditional branches and access to the local cache. Well, I assume it's the local cache. The matrix is 100 x 100 x 8 byte real = 80 kBytes. My understanding is that modern caches are measured in Megabytes.
- Pascal semantics sometimes forces less efficient code.
I'll grant you that. I did wonder if the GPC dynamic schema type that I was so fond of, with its freedom to assign any index range like 1..10 instead of 0..9, can slow things down by forcing an addition before memory access. If the compiler could not figure out how to offset the index register memory access, there would be a slow-down. I'm implementing dynamic arrays with range 1..n in FPC by creating an array 0..n and ignoring the 0 element.
In particular Pascal requires "correct" handling of edge cases and code needed for this may increase runtime
I had forgotten about that. I must look into this, and make sure I have GPC and FPC on a level playing field when it comes to range checking at run-time. It could be that such checks are turned off in FPC and turned on in GPC and this explains the entire difference in execution time.
- bit-packed arrays are particularly inefficient.
I'm not bit-packed arrays. I have packed arrays of bytes for images, but other than that the compiler, for the moement, free to choose the alignment of the fields. I will have to constrain the byte alignment later when I build static libraries to link to C and Fortran. But for now they are unconstrained.
Well, Aplle decided to use LLVM mostly for licencing reasons
The devils.
Now LLVM has accumulated its own warts and partially in response to LLVM GCC folks have done large cleanups.
That's encouraging.
My student made a small compiler interfacing LLVM (he did not want to deal with GCC). In about 2 years his compiler got completely broken by changes to LLVM interface...
Darn it!
Best, Kevan
On 03/06/2020 16:40, Waldek Hebisch wrote:
On Wed, Jun 03, 2020 at 09:03:44AM -0400, Kevan Hashemi wrote:
(8) According to comments in the GPC source files, one of the reasons the GCC team goes ahead and breaks other people's front ends is because they are implementing new optimisation routines. So, we would expect the GCC code to be fast, even if GCC itself is a pain in the neck. But my FPC code runs approximately twice as fast as my GCC code. I tested it inverting 100 x 100 matrices on a Linux machine where I have both GPC and FPC running in 64-bit.
Could you post your benchmark. To say the truth I spent some time looking at assembly code produced by GPC and cases when it was possible to gain significant speedup at assembly level were quite rare.
My guess is the difference may be due to moving to i386 (32 bit) to x86-64 (64 bit). SSE is quite a bit faster than the x87 fpu. While FPC's code generation is definitely not bad, it does lack many transformations that GCC (and LLVM) have. Especially when it comes to loop transforms. On the other hand, perhaps GCC 4.x did not have too many of those yet either.
Well, Aplle decided to use LLVM mostly for licencing reasons: they want to control software on iPhones (so that it is Apple who controls what gets installed on users iPhone), and GPL 3 (used for GCC 4.2 and higher) requires that users have ability to install their own programs.
Since Apple doesn't ship a compiler installed on iOS devices (although perhaps nowadays they kind of do, with Swift Playgrounds), I don't think that would have caused problems. But you're absolutely right a main reason was that they loathe the GPLv3.
BTW. My student made a small compiler interfacing LLVM (he did not want to deal with GCC). In about 2 years his compiler got completely broken by changes to LLVM interface...
Yes, LLVM breaks a lot of middle-end code all of the time as well. Fortunately, their bitcode format is fairly stable (even the text version of it, in spite of them not guarantee any compatibility there at all), so that's what I'm using for FPC's (optional) LLVM code generator backend.
Jonas
Dear Jonas,
My guess is the difference may be due to moving to i386 (32 bit) to x86-64 (64 bit).
There is an increase in speed moving from 32-bit to 64-bit alone, and I'm able to measure that on Linux, because we have both 32-bit and 64-bit GPC on Linux. Here's time of 100x100 matrix inversion on various platforms. I'm running Linux and Windows in Virtual Box on the same MacOS machine.
OS 32/64 GPC/FPC t (ms) MacOS 32 GPC 17 MacOS 64 FPC 3.1 Linux 32 GPC 16 Linux 64 GPC 11 Linux 64 FPC 3.2 Windows 32 GPC 16 Windows 64 FPC 3.0
So 16 ms drops to 11 ms moving from 64-bit to 32-bit on Linux for matrix inversion. In the extreme case of 100% 8-byte transfers, we'd get 50% ddrop in execution time, so I was pleased to see a 30% drop. But you'll see the execution time drops to 3.2 ms when I compile with FPC.
While FPC's code generation is definitely not bad, it does lack many transformations that GCC (and LLVM) have.
In that case, perhaps my FPC matrix inverter is faster because of the changes I had to make in the dynamically-allocated matrix implementation. So I have been looking at the execution time for another type of analysis: differentiating gray-scale images and then identifying unusual squares in the pattern. Now I find that GPC is faster than FPC.
OS 32/64 GPC/FPC t (ms) MacOS 64 FPC 14 Linux 64 GPC 11 Linux 64 FPC 15 Windows 64 FPC 15
So that's 11 ms for GPC and 15 ms for FPC on Linux, Windows, and MacOS.
Best, Kevan
Hard to read through this without commenting.
The issue with GCC is that there is no real intermediate code. Yes, it passes "rtl" to the backend, but it is pretty much designed not to park intermediate form into a file. This is deliberate. The GCC makers realized that if they provided an intermediate form that the backend could get used as a general purpose tool, especially with respect to licencing. That is, there would be nothing to prevent use with a commercial tool set.
In fact, I looked at using gcc as a backend long ago and realized that restriction, and decided against using it. That was about 1993. LLVM is a different story, and that is certainly one reason it took off in popularity.
The other factor in this is designing the compiler in Pascal itself. FPC (for example) SHOULD be less efficient than a full blown C written front end for GCC, since GCC got some world class attention to it's backend. However, as you discovered, the language it was written in was less important than the platform. Its easier to add optimization to FPC than it is to port a GCC front end, because FPC is defined in it's own language.
Is FPC a good Pascal target? The group there has made major strides to embrace the ISO 7185 as a dialect. My only issue with them is that they don't use my help much :) ie, I write HUGE amounts of ISO 7185 tests and they appear to not be using much or any of it, and when they do they don't talk to me (ie., give me any feedback whatever).
If gpc, or a "gpc like" compiler were written for LLVM (or similar), I would suggest that be done in Pascal itself. The phrase is "eat your own dog food", that is, use your own tooling. Writing a compiler in its own language tends to wring out bugs much faster, and tends to force you to provide more of your own infrastructure. GPC (sorry) suffers from this. There are too many places you have to just declare an external call to C to get anything done in GPC.
Scott Franco
--------- Original Message --------- Subject: Re: Plan to Update GPC From: "Waldek Hebisch" hebisch@math.uni.wroc.pl Date: 6/3/20 7:40 am To: "gpc@gnu.de" gpc@gnu.de
On Wed, Jun 03, 2020 at 09:03:44AM -0400, Kevan Hashemi wrote:
Dear Tom,
At least now there is some record and maybe that will help the next person to work on this.
I'll add two more comments that explain why I gave up on the GNU Compiler Collection.
(7) Waldek has GPC compiling on GCC 4.3.5. As I describe in (5) and (6), I was unable to build GCC 4.3.5 on MacOS. But I do have GCC 4.9.4, installed by Home Brew. So I thought, "Surely I can just use 4.9.4, maybe a few tweaks will be required." But no, it's not just a few tweaks. Between GCC 4.3.5 and 4.9.4, the GCC people made dramatic changes to the interface between the front end and the middle end. The file varray.c is gone. The definition of the GENERIC tree structure is scattered through a bunch of new files and is incompatible with the old structures.
My past experience was that I needed about month of work to update to new GCC version (say 4.1 to 4.2). Skipping intermediate versions can save some work. OTOH, since changes are larger more effort goes into finding new way of doing things.
The GCC team claim their objective is to provide a platform upon which we can create front-ends for any and all languages we want. It's the "GNU Compiler Collection". It's a great idea. It's the idea that drew me into GPC and GCC in the first place. We can combine FORTRAN, Pascal, and C and link them into one executable. It was great.
http://www.bndhep.net/Software/Mixing/Mixing_Manual.html
But fundamental to any such endeavor is a firm commitment to backward compatibility. Making dramatic changes to the trees interface that break other people's front ends is absolutely contrary to the "compiler collection" philosophy. The GCC team has abandoned its mission. Maybe they have recovered their sense of direction in the past ten years, since GCC 4, heading into GCC 11, but I doubt it.
Yes. There is "Run with us or get lost" attiude in GCC comunity. Just to keep front end in sync with backend requires substantial work.
And that's when I gave up. I hate C, that's why I program in Pascal. Spending hundreds of hours programming in C to get a Pascal compiler to work was going to be painful.
Sure, understand.
So I switched to FPC. And now I discover that the secondary problems with GCC (it's a pain in the neck) have been obscuring its primary problems.
(8) According to comments in the GPC source files, one of the reasons the GCC team goes ahead and breaks other people's front ends is because they are implementing new optimisation routines. So, we would expect the GCC code to be fast, even if GCC itself is a pain in the neck. But my FPC code runs approximately twice as fast as my GCC code. I tested it inverting 100 x 100 matrices on a Linux machine where I have both GPC and FPC running in 64-bit.
Could you post your benchmark. To say the truth I spent some time looking at assembly code produced by GPC and cases when it was possible to gain significant speedup at assembly level were quite rare. What I have seen were: - tiny routines (especially tiny loops) have kind of random speed, adding useless instrution can make tiny look go faster, moving code to different place in memory can change runtime - Pascal semantics sometimes forces less efficient code. In particular Pascal requires "correct" handling of edge cases and code needed for this may increase runtime - bit-packed arrays are particularly inefficient. Decision to implement bit-packing in GNU Pascal was long ago and probably was a mistake. Here most of blame is on front end, AFAIK GNU Pascal is the only Pascal compiler that implements bit-packing. Theoretically back end could do better job with bit-packing, but it is hard to blame GCC folks that they do not optimize code that almost nobody uses.
Most compile-time optimisation takes place in the middle and back ends, not the front end. So, after all that fuss, and making so much work for Waldek and the rest of the GPC writers, the GCC crew still can't produce efficient code. And because GCC compiles itslef, the compiler itself is slow. Compiling my code with FPC goes twice as fast as compiling with GCC.
My conclusion is that GCC is a disorganised and ineffectual mess. The header and macro arrangement beloved of C has created a monstrous body of code that is almost impossible to compile and is being modified continuously by people who don't want to maintain the version they released six months ago, even though that version was dramatically different from the version they released a year ago. I note that MacOS abandoned GCC, switching to CLANG, and Windows does not appear to use GCC at all. Only on Linux is GCC common, but people are starting to build Linux with CLANG, so we'll see what the future holds for GCC. I'm not optimistic.
Well, Aplle decided to use LLVM mostly for licencing reasons: they want to control software on iPhones (so that it is Apple who controls what gets installed on users iPhone), and GPL 3 (used for GCC 4.2 and higher) requires that users have ability to install their own programs.
LLVM is a fresh start, so it was cleaner due to lack of of old warts. Now LLVM has accumulated its own warts and partially in response to LLVM GCC folks have done large cleanups. And one effect of GCC cleanups is that old interfaces used by GPC got replaced by different ones making GPC porting harder...
BTW. My student made a small compiler interfacing LLVM (he did not want to deal with GCC). In about 2 years his compiler got completely broken by changes to LLVM interface...
-- Waldek Hebisch
_______________________________________________ Gpc mailing list Gpc@gnu.de https://www.g-n-u.de/mailman/listinfo/gpc
Is FPC a good Pascal target? The group there has made major strides to embrace the ISO 7185 as a dialect. My only issue with them is that they don't use my help much :) ie, I write HUGE amounts of ISO 7185 tests and they appear to not be using much or any of it, and when they do they don't talk to me (ie., give me any feedback whatever).
Well, talk is cheap ;) Actually we are using your tests from time to time, I used them to get FPCs ISO support in a reasonable shape and we would happily add them to our regression tests. Problem is: the license is unclear.
If gpc, or a "gpc like" compiler were written for LLVM (or similar), I would suggest that be done in Pascal itself.
FPC has also the possibility to use LLVM as backend for selected targets. Funnily enough, if one does serious LLVM support, it requires also adaption for each target. And the same as for gcc applies as well: new versions normally break existing frontends. Not to mention that a LLVM based compiler is ten times slower than one with FPCs backend. The generated code is on average around 10 % faster thought.
On 13/08/2020 11:33, Florian Klämpfl wrote:
Funnily enough, if one does serious LLVM support, it requires also adaption for each target.
Well, the LL does stand for "low level" :)
And the same as for gcc applies as well: new versions normally break existing frontends.
Nowadays it doesn't happen that often anymore if you use IR or bitcode as intermediary format. Generally, specifying a higher target LLVM version number to FPC mainly results in FPC using features only available in newer LLVM versions.
Jonas
* My only issue with them is that they don't use my help much :) ie, I write HUGE amounts of ISO 7185 tests and they appear to not be using much or any of it, and when they do they don't talk to me (ie., give me any feedback whatever).
Hmm, is this your work https://sourceforge.net/p/pascalp5/ ?
Yes.
Scott Franco
--------- Original Message --------- Subject: RE: Re: Plan to Update GPC From: "Treutwein Bernhard" Bernhard.Treutwein@Verwaltung.Uni-Muenchen.DE Date: 8/13/20 4:26 am To: "gpc@gnu.de" gpc@gnu.de
My only issue with them is that they don't use my help much :) ie, I write HUGE
amounts of ISO 7185 tests and they appear to not be using much or any of it, and when they do they don't talk to me (ie., give me any feedback whatever).
Hmm, is this your work https://sourceforge.net/p/pascalp5/ ?
_______________________________________________ Gpc mailing list Gpc@gnu.de https://www.g-n-u.de/mailman/listinfo/gpc
On 07/05/2020 23:11, Kevan Hashemi wrote:
Another solution is to port GPC to LVVM so we can use the CLANG compilers. The LVVM strategy seem like a good one to me: produce platform-independent code that then gets compiled and assembled. If I understand correctly, a CLANG front-end will work on any platform.
Note that LLVM and clang are two different things. Porting to LLVM would mean rewriting the GPC backend to interface with LLVM instead of with GCC. Also keep in mind that LLVM IR _is_ architecture and OS-specific, so you'd still need to implement and maintain support for every platform if you go that route.
Adding a Clang frontend for Pascal would avoid that issue, but it would probably require writing it from scratch, at least to the extent that you have to write any frontend for any language from scratch when using Clang. I.e., there's obviously a bunch of infrastructure you can use, but there's no Pascal support in it (afaik) and it's unlikely you'd be able to reuse much if any GPC code for it.
Jonas
On May 7, 2020, at 2:11 PM, Kevan Hashemi hashemi@brandeis.edu wrote:
Dear GPC Collaborators,
PROBLEM: MacOS 10.15 does not run 32-bit binaries. My application uses 30k lines of GPC code. The MacOS GPC is 32-bit only.
MY FAILURE ON MACOS: The current GPC is compatible with the back-end of GCC 3.4.6 only. The procedure on all platforms is to compile gcc3.4.6 with the GPC sources. With a variety of C-compilers on MacOS (CLANG, GCC-4.9, GCC-5, and GCC-8), I can produce the two cross-compiler executables xgcc and xgpc. These are x86_64 executables. They both compile "Hello World", but they produce only 32-bit objects. When I pass "-m64", they say "Sorry: 64-bit not compiled in". I try building GCC 3.4.6 alone with:
config --target=x86_64-apple-darwin make
But I get, "Configuration x86_64-apple-darwin16.7.0 not supported". When I apply the same procedure to the GCC 4.9.4 sources, the build proceeds. The GCC 3.4.6 sources support 64-bit targets on Linux, so I was hoping it could do the same on MacOS. I have examined the GCC literature and the contents of gcc/config, but I still don't know what file should be present to provide x86_64 support on apple-darwin. Unless someone tells me otherwise, I'm going to assume that getting the 64-bit MacOS GPC out of GCC 3.4.6 is impossible.
It has been a long time but IIRC we got a 4.x.x based GPC 64 bit x.86 target working. At the time though we couldn't get a PPC_64 version working so the effort was put on hold pending finding a fix for PPC_64. This was around the 10.5/10.6 days. (Look at Waldek's git repository for 4.x.x based GPC sources and patches.)
I'd have to dig back in mail archives to see if I'm remembering correctly, but I think the issue with a MacOS GCC 3.4.6 base is/was that there didn't exist a 64 bit MacOS runtime until after GCC 4.x.x became the only actively developed/maintained version. (There might also have been a lack of MacOS specific PPC_64 code generation also but that's a mute issue now.) I've got a dim memory that there might have been an issue with multi-lib support that was needed but didn't exist for building a MacOS GCC 3.4.6 base.
Since those days, Apple has switched from a GNU based toolchain to a LLVM based toolchain which wrecks havoc with build processes expecting a GNU compatible toolchain command set. You can work around most of the problems with using a Homebrew or MacPorts GCC but there's no way that I could find to get around using Apple's system supplied linker. For Apple's linker there's three different linker specs required to get GPC/GCC working depending upon the OS version target - 10.6 or earlier, 10.7, and 10.8 or later (I won't rule out changes since I last looked into it). With a 3.4.6 based GPC, there was a separate specs file so you could fix up linker specs issues by modifying that file. That no longer works with 4.x.x and later compilers since the specs gets compiled into the compiler itself. I think the linker specs issue can be solved by back porting the linker spec code from the late 4.x GCC version code to the earlier version GCC code that Waldek's 4.x.x code builds with.
IIRC, I also ran into 10.11/10.12 issues in getting the GPC rts built. I'd have to really do some digging but I think there was problem in a rts build program (or build testing/checking program) that I found a temporary hack workaround for. (There's auto generated files involved and I hadn't yet chased back to the base source a non-hackish fix.) There was also an issue or two with changes C standard library function prototypes in I think the math area. (IIRC, the C math function issues showed up in later GCC 4.5.x/4.6.x ish versions and fixes were found that looked like they might be back portable to earlier GGC 4.x.x versions.) Those IIRC didn't show up until you got to the bootstrapping stage and it was causing autoconfig problems. Before I got very far in solving that issue, I had to put the project on hold for more pressing issues and haven't revisited it since.
Translating all my beautiful, reliable GPC code into another language does not sound like fun. Porting GPC to a newer version of GCC, such as GCC 8, is a possibility, but I understand that the GCC back-end team has a history of being uncooperative with the GPC team. Another solution is to port GPC to LVVM so we can use the CLANG compilers. The LVVM strategy seem like a good one to me: produce platform-independent code that then gets compiled and assembled. If I understand correctly, a CLANG front-end will work on any platform.
I ran into quite a few problems in trying to build GPC with CLANG compilers. I couldn't find a gcc C dialect language option for CLANG that worked to compile the GPC code base. Even newer version gcc's barf on the way older version dialect gcc code used in the GPC sources but at least as far as gcc 5.x (I think was a the latest I tried) there was a language dialect option you could use so the GPC sources would compile without language version issues. Now that I think of it, I think I also ran into assembly language dialect issues with Apple's CLANG based assembler and I changed config options to use GNU gas for assembling into machine code before linking.
I would like to hear your advice. I have to solve this problem. I have allocated one thousand hours of my time to get it done. If there is a way to revive GPC with that amount of labor, I'll do it.
I think porting GPC to LLVM might be a dicey proposition. The project will be pretty much on its own with no help except for an over a decade old Apple GCC front end port example to help in figuring out what might work on an old, outdated LLVM code base.
You might try spending a week or two on Waldek's 4.x.x code base to get a better idea of the magnitude of the work effort involved with that avenue. If practical, make sure you do it on a MacOS 10.15 machine so you get better idea of what issues Apple's every changing system configuration will arise using the relative old GCC/GPC 4.x.x code base. (I seem to recall Apple reorganized the system headers structure in the 10.8/10.10 timeframe that caused a few problems.)
Gale Paeper gpaeper@empirenet.com
-
Bastiaan Veelo -
Florian Klaempfl -
Florian Klämpfl
-
Gale Paeper -
John Ries -
Jonas Maebe -
Kevan Hashemi -
Paul Isaacs -
Schneider, Thomas (NIH/NCI) [E] -
scott andrew franco -
Thomas Schneider
-
Treutwein Bernhard -
Waldek Hebisch