From nobody Mon Dec 1 16:57:25 2025 X-Original-To: arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4dKqp66p2zz6JtVR; Mon, 01 Dec 2025 16:57:34 +0000 (UTC) (envelope-from tpearson@raptorengineering.com) Received: from raptorengineering.com (mail.raptorengineering.com [23.155.224.40]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4dKqp53WTMz3kky; Mon, 01 Dec 2025 16:57:33 +0000 (UTC) (envelope-from tpearson@raptorengineering.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=raptorengineering.com header.s=B8E824E6-0BE2-11E6-931D-288C65937AAD header.b=r7TFq8Md; dmarc=pass (policy=quarantine) header.from=raptorengineering.com; spf=pass (mx1.freebsd.org: domain of tpearson@raptorengineering.com designates 23.155.224.40 as permitted sender) smtp.mailfrom=tpearson@raptorengineering.com Received: from localhost (localhost [127.0.0.1]) by mail.rptsys.com (Postfix) with ESMTP id 865E47790D6A; Mon, 1 Dec 2025 10:57:27 -0600 (CST) Received: from mail.rptsys.com ([127.0.0.1]) by localhost (vali.starlink.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id 1p566O2pJ5EX; Mon, 1 Dec 2025 10:57:25 -0600 (CST) Received: from localhost (localhost [127.0.0.1]) by mail.rptsys.com (Postfix) with ESMTP id BC2AC7790ED9; Mon, 1 Dec 2025 10:57:25 -0600 (CST) DKIM-Filter: OpenDKIM Filter v2.10.3 mail.rptsys.com BC2AC7790ED9 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raptorengineering.com; s=B8E824E6-0BE2-11E6-931D-288C65937AAD; t=1764608245; bh=hwCyOqUps+UJnnq9XOrVikpdfqF7eFqTwhieejn8Mrg=; h=Date:From:To:Message-ID:MIME-Version; b=r7TFq8Md/JY+FWcWFq6fpqRSyKvnuTY7SiHWwCRYV/JxmCT12f7PKdyFgQl3Fzrct kouAOx76TYnFG3mQ8eXsJUnOiLvqS3Rfi7EZVfin+giiDzWD591lWjjVE2rcS2Inoo DCQnvR/5VzcQE8r5zBcEzvVr7m8a+C+0tYhQMEjA= X-Virus-Scanned: amavisd-new at rptsys.com Received: from mail.rptsys.com ([127.0.0.1]) by localhost (vali.starlink.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id jThQij2RQ3nk; Mon, 1 Dec 2025 10:57:25 -0600 (CST) Received: from vali.starlink.edu (localhost [127.0.0.1]) by mail.rptsys.com (Postfix) with ESMTP id 92CFF7790D6A; Mon, 1 Dec 2025 10:57:25 -0600 (CST) Date: Mon, 1 Dec 2025 10:57:25 -0600 (CST) From: Timothy Pearson To: Piotr Kubaj Cc: Al , Poul-Henning Kamp , Minsoo Choo , Warner Losh , "freebsd-arch@freebsd.org" , freebsd-ppc Message-ID: <526620325.132622.1764608245446.JavaMail.zimbra@raptorengineeringinc.com> In-Reply-To: References: <202511261707.5AQH7N1u016543@critter.freebsd.dk> <529626383.127814.1764191318804.JavaMail.zimbra@raptorengineeringinc.com> Subject: Re: What's the plan for powerpc64 in FreeBSD 16 List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Mailer: Zimbra 8.5.0_GA_3042 (ZimbraWebClient - GC142 (Linux)/8.5.0_GA_3042) Thread-Topic: What's the plan for powerpc64 in FreeBSD 16 Thread-Index: u/ZD14EfZidaCn83KvYEPaiCmJzZ2w== X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.98 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.98)[-0.977]; DMARC_POLICY_ALLOW(-0.50)[raptorengineering.com,quarantine]; R_DKIM_ALLOW(-0.20)[raptorengineering.com:s=B8E824E6-0BE2-11E6-931D-288C65937AAD]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; FREEFALL_USER(0.00)[tpearson]; MIME_TRACE(0.00)[0:+]; TO_DN_ALL(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; RCPT_COUNT_SEVEN(0.00)[7]; RECEIVED_HELO_LOCALHOST(0.00)[]; RCVD_COUNT_FIVE(0.00)[5]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MLMMJ_DEST(0.00)[arch@freebsd.org,freebsd-ppc@freebsd.org]; DKIM_TRACE(0.00)[raptorengineering.com:+] X-Rspamd-Queue-Id: 4dKqp53WTMz3kky ----- Original Message ----- > From: "Piotr Kubaj" > To: "Timothy Pearson" > Cc: "Al" , "Poul-Henning Kamp" , "Minsoo Choo" , "Warner > Losh" , "freebsd-arch@freebsd.org" , "freebsd-ppc" > Sent: Saturday, November 29, 2025 5:15:40 AM > Subject: Re: What's the plan for powerpc64 in FreeBSD 16 > On 25-11-26 15:08:38, Timothy Pearson wrote: >> >> >> ----- Original Message ----- >> > From: "Piotr Kubaj" >> > To: "Al" >> > Cc: "Poul-Henning Kamp" , "Minsoo Choo" >> > , "Warner Losh" , >> > "freebsd-arch@freebsd.org" , "freebsd-ppc" >> > >> > Sent: Wednesday, November 26, 2025 3:01:26 PM >> > Subject: Re: What's the plan for powerpc64 in FreeBSD 16 >> >> > On 25-11-26 15:47:38, Al wrote: >> >> >> >> On Wed, 26 Nov 2025, Poul-Henning Kamp wrote: >> >> >> >> > Date: Wed, 26 Nov 2025 17:07:23 +0000 >> >> > From: Poul-Henning Kamp >> >> > To: Minsoo Choo >> >> > Cc: Warner Losh , >> >> > "freebsd-arch@freebsd.org" >> >> > Subject: Re: What's the plan for powerpc64 in FreeBSD 16 >> >> > >> >> > Minsoo Choo writes: >> >> > >> >> >> After reading replies, I still have questions why we should keep powerpc64be. >> >> > >> >> >> Second, regarding arguments about keeping big-endian support in codebase even >> >> >> if no one actually physically runs the code: >> >> >> This also applies to leaving 32-bit code (armv7) in tree for future >> >> >> compatibility. >> >> > >> >> > I think that is a bit of a leap, although in principle I agree. >> >> > >> >> > However, I am much less convinced that a relevant new 32 bit platform >> >> > will appear, than that somebody comes out with a 64 BE platform. >> >> > >> >> > Bit-rot is a thing, and unless we are willing to say "Screw anybody >> >> > silly enough to create BE platform now or in the future" we should >> >> > still guard against it. >> >> >> >> There is a number of new PowerPC 64 BE systems: >> >> A1222 >> > BE, but not 64-bit. It's supported via powerpcspe port on FreeBSD, which >> > is already deprecated along with powerpc. >> >> Sam460 several versions >> > I'm not sure about that, I think it's also 32-bit. >> >> Mirari (New PPC hardware) >> > This one will be ugly, similarly to e5500. e5500 is 64-bit, but without >> > Altivec, so it's below the usual baseline. Mirari will use e6500. e6500 >> > supports BE with Altivec. It also supports LE, but without VSX. The >> > current baseline for LE is POWER8, which supports VSX. >> > e5500 works on FreeBSD, but requires building everything on your own, >> > along with the OS itself, by using CPUTYPE?=e5500 in make.conf, >> > otherwise Altivec instructions will be issued by clang. If we ever get >> > binary packages on powerpc64, e5500 users will still need to build their >> > own because of that. >> >> If that's correct, then ABIv2 would be broken in LE mode, making LE mode even >> less useful on that hardware. I really don't want to be forced to keep the >> early ABI support around just for quite old, fairly quirky cores. > > Why? ELFv2 itself works fine without VSX, e.g. on G5 and e5500, on BE. > Why would running on LE specifically require VSX if the binaries are > built without VSX? ABIv2 requires the use of VSX registers for argument passing. It's possible this still works at a hardware level on these devices, or that we simply haven't hit the spill level where they are needed for most (all?) function calls in practice. Regardless, it's a point of concern for legacy, non-OpenPOWER compliant hardware.