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 AA14A63A0 for ; Thu, 11 Jan 2024 03:24:42 +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 40B3KfbM1734724 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 11 Jan 2024 03:20:42 GMT Reply-To: From: To: "'brian m. carlson'" Cc: "'Taylor Blau'" , "'Junio C Hamano'" , "'Dragan Simic'" , References: <006b01da4412$96c6c500$c4544f00$@nexbridge.com> <007c01da4420$10a7b700$31f72500$@nexbridge.com> In-Reply-To: Subject: RE: [DISCUSS] Introducing Rust into the Git project Date: Wed, 10 Jan 2024 22:24:25 -0500 Organization: Nexbridge Inc. Message-ID: <00a801da443d$b1539670$13fac350$@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+QKEQ1wBALH7sDwDPprtZwK9Rr3fAtB2bewC03OFJa16Islg On Wednesday, January 10, 2024 9:56 PM, brian m. carlson wrote: >On 2024-01-10 at 23:52:21, rsbecker@nexbridge.com 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.