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