Re: Plan to Update GPC

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 [email protected] 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-migrate-to-d/

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
>
>