From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from secure.elehost.com (secure.elehost.com [185.209.179.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 7539C5812E for ; Thu, 11 Jan 2024 21:28:43 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=nexbridge.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=nexbridge.com X-Virus-Scanned: Debian amavisd-new at secure.elehost.com Received: from Mazikeen (cpebc4dfb928313-cmbc4dfb928310.cpe.net.cable.rogers.com [99.228.251.108] (may be forged)) (authenticated bits=0) by secure.elehost.com (8.15.2/8.15.2/Debian-22ubuntu3) with ESMTPSA id 40BLOQY51894419 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 11 Jan 2024 21:24:27 GMT Reply-To: From: To: "'Trevor Gross'" Cc: "'brian m. carlson'" , "'Taylor Blau'" , "'Junio C Hamano'" , "'Dragan Simic'" , References: <006b01da4412$96c6c500$c4544f00$@nexbridge.com> <007c01da4420$10a7b700$31f72500$@nexbridge.com> <00a801da443d$b1539670$13fac350$@nexbridge.com> In-Reply-To: Subject: RE: [DISCUSS] Introducing Rust into the Git project Date: Thu, 11 Jan 2024 16:28:10 -0500 Organization: Nexbridge Inc. Message-ID: <01c101da44d5$175f1100$461d3300$@nexbridge.com> Precedence: bulk X-Mailing-List: git@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Content-Language: en-ca Thread-Index: AQNL0k5wzhXZATyUnQ76Vxjn4eCV+QKEQ1wBALH7sDwDPprtZwK9Rr3fAtB2bewC03OFJQI1asehASnAJU6tYFrYQA== On Thursday, January 11, 2024 3:08 PM, Trevor Gross wrote: >On Wed, Jan 10, 2024 at 10:24=E2=80=AFPM = wrote: >> >> 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. > >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.