On Wednesday, January 10, 2024 9:56 PM, brian m. carlson wrote: >On 2024-01-10 at 23:52:21, rsbecker@xxxxxxxxxxxxx wrote: >> Unfortunately, none of the compiler frontends listed previously can be >> built for NonStop. These appear to all require gcc either directly or >> transitively, which cannot be ported to NonStop. I do not expect this >> to change any time soon - and is outside of my control anyway. An >> attempt was made to port Rust but it did not succeed primarily because >> of that dependency. > >Can you tell us what the technical limitations are that prevent GCC from being >ported so we can understand better? I know LLVM doesn't support ia64, which you >do support, but GCC is very likely the most portable compiler on the planet and >supports architectures and OSes I've never otherwise heard of. > >I strongly suspect that if GCC did end up on NonStop, Rust would be able to be >ported, too, and you'd also get access to gccgo, which would make Git LFS possible >on NonStop as well[0]. > >I'm not capable of porting GCC, but I have done some portability work in the Rust >ecosystem, and I'd be willing to provide context and some assistance (within my >time and capabilities) to help get Rust working on NonStop if you want. > >[0] For the record, as a maintainer of Git LFS, I'm happy to accept portability >patches for virtually any OS. There are a number of issues for porting gcc (and Go). The list is fairly long, but the summary of what I encountered directly (on the last funded effort of 3) is: 1. There are C syntax constructs required to do anything useful (required for access to the OS API) on NonStop that are not in gcc. I can hand code the parser for that, but it would take time. 2. The Big Endian x86 architecture is weird to gcc and making that work is not easy. 3. There is no assembler on NonStop. 4. The ELF header is very different from standard. 5. The symbol table structure is radically different, so debugging would be (nearly) impossible or impractical. gdb was ported to account for the platform differences. 6. The linkage structure is similar but different from standard. 7. The external fixup structure is radically different. 8. The loader does not work the same way, so there are required sections of the ELF files on NonStop that are not generated by gcc. There are more, but I just did not get to the point if hitting them. Part of my own issue is that I have expertise in parsing and semantic passes of compilers, but my code generation skills are not where I want them to be for taking on this effort. Our last funded attempt had a code generation expert and he gave up in frustration. If I was hired on to do this, it might have a chance, but at an estimate (not mine) of 4-5 person years for a gcc port, best case, my $DAYJOB will not permit it. If gcc could be ported to NonStop, it would solve so many problems. I have heard of numerous failed efforts beyond what was officially funded by various companies, so this is considered a high-risk project.
