On Thursday, January 11, 2024 3:08 PM, Trevor Gross wrote:

On Wed, Jan 10, 2024 at 10:24 PM [off-list ref] wrote:

quoted

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:

quoted

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.

quoted

2. The Big Endian x86 architecture is weird to gcc and making that work is not

easy.

quoted

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.

quoted

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.

quoted

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.

quoted

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.

quoted

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.

Out of curiosity - does the Tandem compiler (assuming that is the correct name)
have a backend that is usable as a library or via an IR?

If so, maybe it would be possible to write a rustc_codegen_tandem backend like the
three that exist (rustc_codegen_{llvm,gcc,cranelift}
at [1]. GCC and cranelift are still under development). This way you sidestep a lot of
the codegen-specific problems listed above.

I am, of course, not suggesting this as a solution for git and am sure you would
rather have GCC support. But I wonder how feasible this would be if Rust on
NonStop is desired at some point.

The usable compilers and interpreters on NonStop are c89, c99 (what we use for git), c11, perl, and python3 (for the x86 only). The perl and python do not have sufficient modules to do what would be needed by git. The compilers are invoked using a CLI and are not callable using a library. gcc is, for all intents and purposes, not possible - so anything requiring gcc (for example, Rust), cannot be built.  There is no back-end pluggable component for any of the compilers.