Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:127729
Precedence: bulk
MIME-Version: 1.0
References: <faff22ce-dcb9-4013-80d9-ceddd0de5a12@mabe.berlin>
 <73D7B135-ABF8-4EFC-BF16-EA26A5BD1B7A@cmpct.info> <f25b9bdb-e2dd-4498-ba84-98001ccc8746@mabe.berlin>
In-Reply-To: <f25b9bdb-e2dd-4498-ba84-98001ccc8746@mabe.berlin>
Date: Fri, 20 Jun 2025 10:15:27 +0200
Message-ID: <CAJmy8YGCoFyWK1d9mLF7Pj=XrRm7p0By6NY3MfxAjq-oBwwicA@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] Drop support for 32bit builds
To: Marc Bennewitz <marc@mabe.berlin>
Cc: internals@lists.php.net
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
From: divinity76@gmail.com (Hans Henrik Bergan)

On Fri, 20 Jun 2025 at 09:15, Marc Bennewitz <marc@mabe.berlin> wrote:
>
>
> On 19.06.25 18:08, Calvin Buckley wrote:
>
> I think the biggest arguments against this would be:
>
> - embedded systems; think of PHP in use for i.e. router web UIs. While I
> suspect a lot of these are going to be i.e. AArch64/RV64 in the future,
> there might be a long tail of existing systems. Of course, how many
> would upgrade to PHP 9?
>
> While new deployments trend toward 64-bit (e.g. AArch64), there's definit=
ely a long list of devices =E2=80=94 particularly in legacy environments =
=E2=80=94 still running 32-bit systems. But realistically, how many of thes=
e will ever upgrade to PHP 9? Probably very few. These systems often stay l=
ocked to whatever version was originally shipped, and their vendors are unl=
ikely to invest in major version bumps.
>
> - WebAssembly; I don't know how widespread the Memory64 proposal is yet.
> We're using WebAssembly in the docs pages for runnable examples.
>
> I don't know either. ChatGPT tells :
>
> > The Memory64 proposal was formally standardized (Phase 4) in November=
=E2=80=AF2024, backed by strong votes and endorsement from the WASM Communi=
ty Group.
> >
> > It's enabled by default in Firefox 134 and Chrome 133+, with Safari sti=
ll working on implementation.
> >
> > Major runtimes like V8, Wasmtime, Wasmer, WASM2C support Memory64
> >
> > Toolchains including LLVM, Emscripten, Binaryen, WABT support it; WASI=
=E2=80=91SDK has patches in progress
>
>
> And some niche cases like i.e. iSH (which emulates x86-32 on iOS).
>
> This seems to be for very niche projects in itself already and running PH=
P within such is even more niche - if present at all (outside of "because I=
 can" reasons).
>
> The other options include making zend_long always 64-bit and accept the
> performance penalty for 32-bit, or making 32-bit best-effort rather than
> providing any guarantees.
>
> Is int64_t (size of long long 8) available on all systems (like WebAssemb=
ly)?
>
> The downside here, please correct me if I'm wrong, is that this increases=
 complexity instead of reducing it for how much value?


>This seems to be for very niche projects in itself already and running PHP=
 within such is even more niche - if present at all (outside of "because I =
can" reasons).

3v4l.org use 32bit WASM php in production, see it for yourself at
https://3v4l.org/