Pokud podporujou jakoukoliv jinou 32-bit architekturu, tak zahodit 32-bit x86 je největší blbost, co můžou udělat.
Nejde o to, že by snad někdo ten 32-bit Firefox chtěl používat na dnešním HW, jde o to, že to je nejdostupnější 32-bit platforma, takže jakýkoliv "32-bit problém" se dá latit přímo na HW, který téměř každý má.
Mně se zdá, že to vidíš strašně jednoduše. Ale nikdo ti nebrání jít za nimi, říct jim svůj názor a přidat se k nim. Když takových lidí seženeš víc, třeba si budeš moc vymyslet i něco exotičtějšího. Možná tě tohle co píšu nas**e, ale pravda je, že šikovných lidí ubývá...není dost rukou...
To je jen moje zkušenost.
Když jsem dělal porty nějakého softu na 32-bit ARM, tak jsem si to první ladil hezky na 32-bit x86, abych to na tom ARMu měl tak nějak "skoro" funkční. A když se objeví problém a udělám repro na workstation, tak mi to zase ušetří práci.
Já chápu, proč už nechcou distribuovat 32-bit binárky (je to na prd), ale podporu pro 32-bit bych si nechal pro interní účely.
No oni se rozhodli jinak.
Nejsou lidi...
BTW, Firefox byl široce rozšířený, ale díky šíleným zněnám UI, kdy chtěli být "moderní", a v podstatě hromadu lidí vyhnali bičem. A čím méně lidí, tím méně zdrojů.
6. 9. 2025, 21:18 editováno autorem komentáře
> repro na workstation, tak mi to zase ušetří práci.
Teoreticky ano, ale platformy sa mozu lisit aj v inych veciach. Konkretne arm a intel aj v memory coherence, takze multithreadovy program vie na arm zakapat na veciach, co na inteli prejdu. Moze to byt potom prekvapko, ktore sa neda repro na workstation.
Nejvíc problému je s tím, že to je 32-bit.
V dnešní době pro 32-bit člověk nedělá vývoj, spíš se to zkusí až na CI, atd...
No a vzhledem k tomu, že AArch64 má stejný paměťový model jako AArch32, tak to není problém, protože pro AArch64 se normálně testuje a ti co jedou na Apple Silicon to mají jako primární architekturu.
Takže zase zbývá ten 32-bit...
Je to opensource, nic vam preci nebrani si forknou a udrzovat svoji vetev fungujici na 32-bitu, kdyz bez toho nemuzete zit :-) 64bit x86 procesory jsou tu s nami uz pres dvacet let. To, ze tam nekdo ze setrvacnosti bezel v 32bit modu opravdu neni duvod i po letech nutit vyvojare v upstreamu udrzovat vicemene mrtveho kone. Ostatne i Firefox ma nejakou telemetrii (a zdaleka ne kazdy ji vypina, takze to rozhodnuti je oprene i o nejaka data... plus pracuji s tim, ze obecne i z Linuxu 32bit x86 pomalu, ale jiste mizi, ostatne je to videt i na Debianu.
Mě je to úplně fuk. Už jsem napsal důvody, proč bych si to nechal já. A nemusí to ani kompilovat pro ostatní...
A právě protože nejsou zdroje, tak bych si to nechal. Jednodušší to chytat na x86 než na nějakém 32-bit ARMu.
Slysel jste nekdy o vyssim programovacim jazyce?
Nikdo nepise FF v assembleru..
Podporovat 32 a 64 bit na urovni aplikaci (nebo kernelu) je jen otazkou slusne kultury.
Pokud delate prasarny v kodu - tak rozdil 32/64 bit nebude vas jediny problem.
Zrovna u x86 architektury není moc rozdíl v 32-bit a 64-bit JIT, pokud je to napsané alespoň trochu slušně. Firefox i Chrome stejně používá SSE2 (žádné FPU), takže výhoda 64-bit architektury je spíš v těch více registrech, atd... Ale to je jen bonus pro výsledný kód, na algoritmy pro alokaci registrů a další věci toto nemá žádný vliv.
> na algoritmy pro alokaci registrů
Urcite? 32-bit x86 ABI ma 8 (5) general purpose registrov, 64 bit ich ma trosku viac (a APX ich rozsiri na 32, rovnako ako ma aarch64). Takze algoritmus alokacie registrov nemusi riesit take tlaky, ako riesi na i686.
Jako věřil bych, že X86 a x64 bude často blíž než x64 a AArch64, ale myslím, že různých rozdílů (např. volání funkcí), které mohou v důsledku něco zkomplikovat (a vyžádat si ladění nějakých specifických bugů), tam taky nemusí být úplně zanedbatelně. A I kdyby toho nebylo tolik, jsme pořád někde jinde než „Podporovat 32 a 64 bit na urovni aplikaci (nebo kernelu) je jen otazkou slusne kultury.“. Pro většinu aplikací to platit bude, ale zrovna u prohlížeče úplně ne.
Zanedbatelné to je. Je potřeba si dát otázku, co bylo první. 32-bit x86 je prostě nejvíc odladěná architektura co vůbec existuje. Calling conventions není problém a v 32-bit světě se toho stejně za poslední 2 dekády moc nedělo - to spíš v 64-bit světě - třeba přidaný __vectorcall, atd...
JIT většinou má vlastní konvence a komunikuje přes C-ABI.
Firefox pouziva celou skalu knihoven ktere maji HW optimalizace pro jednotlive platformy - ffmpeg, skia, cairo a podobne.
Dalsi vec je release management - prekladani binarek a jejich testovani stoji penize (nekde jsem videl rozpocitane naklady na 1 release a nebylo to uplne malo).
Pokud se vyhodi i686, znamena to ze vsechny zmeny co jdou do Firefoxu (skoro kazdy commit) se uz nebude muset prekladat a testovat na i686 (viz treba https://treeherder.mozilla.org/jobs?repo=autoland)
32-bit je už prostě překonané. Něco jako kdysi 16 na 32...
Pokud firma jede své cnc stroje v 32 bit tak neni problém dát starší verzi, víc nepotřebuje...
Je to překonané a v dnešní době ztráta času..
Pamětníci "neeeeee neni to ztráta času" ... ale řekněte mi, když jste si koupil za posledních 10 let PC, nebo sestavoval... chtěl jste only 32? ne... 64...
Ono to je vse o SW a jak ho pisete - ja si klidne i na 8-bitovem AVR muzu pristupovat na SDXC a gigabajtove ExFAT karty.
Nevidim duvod aby mnohem vykonnejsi 32-bit stroj s neporadil na mistech opravdu nutnych s 64-bit hodnotou. A i 32bit Linux umi pracovat s >4GB souborama, ne ze ne, API tam na to je.
Rozil mezi 16 a 32 na PC je mnohem vetsi (chraneny rezim a strankovani vam neco rika?)
A pocitace nejsou jen x86/64 ... to jste si svet IT velice zjednodusil.