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