Vlákno názorů k článku
Valve tajně sponzorovalo emulátor x86 na ARM64 FEX od Karel z vesnice bez vodovodu - Aha, takze nejdriv cez ten emulator emulujeme x86...

A presne tohle (spotreba nejakyho lowend kramu) nezajima naprosto vubec nikoho.

Zato uplne vsehny zajima, ze jim na tom nebudou fungovat jejich aplikace bud vubec (90%) nebo se silenejma problemama jak se samotnou funkcnosti tak se zasadnim propadem vykonu.

Uplne vsichni taky maji celou radu zkusenosti na tema MS a jejich support non x86 platforem, takze neexistuje jedinej vyvojar, kterej by se 10 minut zaobiral myslenkou, ze bude neco delat aby to na tom jelo nativne.

Spotřeba zajímá lidi spíše zprostředkovaně skrze výdrž na baterku a hlučnost (při zachování rozumné hmotnosti).

8. 12. 2025, 10:20 editováno autorem komentáře

bez prezdivky ...> Kolik non-x86 platforem od Microsoftu jsi měl? Vedle Windows on ARM mám ještě Itanium, Alpha a PowerPC, takže můžu porovnávat. Většina lidí si nevšimne, že něco nefunguje - Microsoft (a Apple) implementoval všechny instrukce Intelu a všechna grafická API. A protože má moderní ARM s 8 instrukcemi za cykl výkonu na rozdávání, propad výkonu neřešíš. I s ním si podával Snapdragon X Elite soudobý Intel v legacy x86 aplikacích a X2 má mít o polovinu větší výkon.

Stačí si vzpomenout na mobilní platformu, kdy Windows Mobile (v různých verzích) bylo nahrazeno za nekompatibilní Windows Phone 7 Series aby za dva roky to bylo nahrazenou opět za nekompatibilní Windows Phone 8. A po těchto změnách to přestalo uživatele i programátory bavit.

Měl jsi mobilový Windows v ruce? Já pro to i programoval. Aplikace pro WindowsPhone 7 jely až do nějaké verze Windows 10M. Tehdy ten systém umřel kvůli Googlu, který blokoval své služby. Zakázal právníky 3rd party aplikaci pro přehrávání YouTube, ale s dokončením webové HTML5 verze počkal až na konec Windows 10M. Konkrétně implementace reklam, takže nejela v prohlížeči monetizovaná videa. Podobně Google Docs. Kdo pamatuje, že měly mobilní webovou verzi? Vypadala stejně jako app a uměla všechno kromě běhu offline. Když zjistil, že ji lidé z Windows mobilů používají, tak ji zrušil. Neobnovili dodnes, takže např na telefonu s Linuxem máš smůlu.

Kdyby ta platforma neumřela, tak by pokračovala plnohodnotným desktopovým režimem. Připojit monitor, klávesnici, myš šlo, časem by přišlo plné Win32 API a emulátor x86. Hackeři pak zvládli nainstalovat desktopový Windows on ARM na Lumii.

8. 12. 2025, 12:38 editováno autorem komentáře

Měl jsem asi 6 let HTC Touch Diamond, telefon za 11 000 kč, což v té době nebyly malé peníze, běžící na Windows Mobile 6.1 takže jsem to sledoval doslova na živo. Telefon to byl super, jen po poměrně krátké době na to nebyl žádný nový software. A když jsem v průběhu vlastnictví toho HTC viděl jak Microsoft 2x zařízl zpětnou podporu, tak jsem pak samozřejmě přešel na Android. Nebyl jsem blázen abych čekal až to zas Microsoft zařízne. A zjevně jsem nebyl sám.

Taky jsem měl ty Windows CE, Windows Pocket apod, jak to bylo pod různými názvy ten samý OS. Nevěděl jsem, že vyšla i dotyková verze. Já znám i mobily, že potřebovaly stylus. Ten systém umřel sám, roky před příchodem WindowsPhone 7, tedy ten na to neměl vliv a není divu, žes tam neměl žádné aplikace (dokonce se instalovaly z PC, ne?).

8. 12. 2025, 13:07 editováno autorem komentáře

HTC s Touch Diamond začali používat jejich vlastní shell, který měl ovládací prvky použitelné prstem. Ale byl to pořád Windows Mobile, a velká část aplikací bez stylusu moc ovládat nešla (ten telefon měl rezistivní display a stylus)

Jediný opravdu dotykáč s Windows Mobile o kterém vím byl jejich poslední Windows Phone mobil, HTC Touch HD 2. Skvělý telefon, ale to že měl kapacitní display ho dost sráželo, ten OS a aplikace na to prostě nebyly dělané. Naštěstí do toho šel neoficiálně flashnout Android.

8. 12. 2025, 16:06 editováno autorem komentáře

Díky, tím se to vysvětluje. Hack neboli nadstavba od výrobce telefonu. Jinak telefon samozřejmě může mít obě vrstvy, rezistivní pro stylus a kapacitní pro prsty. Koneckonců i dnes jsou mobily a tablety, které umí stylus.

Kombinace rezistivní + kapacitní možná reálná je, ale nedává smysl. Rezistivní display už z principu vyžaduje flexibilní dotykovou vrstvu, která se prohne v místě dotyku a uzavře kontakt. Což je nepraktické u dotykáče, protože znepříjemňuje gesta (Prst o to víc drhne). A k tomu je náchylná na poškrábání. Současné mobily mají speciální digitizéry (wacom, ntrig, whatever). Díky tomu umí i přítlak, což u rezistivního... sice částečně šlo, ale nebyla to žádná sláva. Rezistivní display se podle mě ujal hlavně díky kombinaci přesnosti a ceny.

8. 12. 2025, 17:08 editováno autorem komentáře

Windows Mobile, včetně těch na HTC Touch Diamond, ovládal typicky prstem. Chtělo to trochu přesnosti, ale šlo to.

Měl jsem pár kousků s PocketPC/Windows CE/Mobile, počínaje HP iPAQ H3650. Tehdy to bylo celkem extravagantní, mít PDA třeba s GPS a mapami. Když se lidé ptali, jestli by to nebylo i pro ně, tak jsem těm netechnickým upřímně říkal, že taková zařízení umí spoustu věcí, ale kvůli hromadě quirks to pro běžného uživatele moc není.

U Windows Phone to bylo jiné. Ty byly uživatelsky skvělé, velmi rychlé, a se skvěle plynulým UI. Bohužel přišly pozdě, bohužel bez zpětné kompatibility, bohužel v první verzi s omezením multitaskingu. Ballmer silně podcenil situaci. Každá další verze toho uměla víc, rychlost a plynulost zůstávala. Až do přechodu na Windows 10 Mobile, kde ani MS u svého HW nezvládl implementaci, a například se mi sekalo audio (u předchozích verzí nevídáno).

Konec Windows Phone/Mobile mě fakt nepotěšil. Dodnes mám jeden kousek od HTC doma se SW generátorem bílého šumu připojený k repráčku. Na svém hlavním telefonu mám Android s launcherem Square Home vyladěným tak aby vypadal co nejvíc jako Windows 10 Mobile. Není to dokonalé, Windows se to nevyrovná, ale ze všech těch launcherů mi to osobně přijde nejvíce přehledné a použitelné.

9. 12. 2025, 21:08 editováno autorem komentáře

Já jsem na WinMo používala SPB Mobile Shell, který ovládání prstem zvládal dobře. Ale spousta běžných aplikací byla fakt dost nepohodlná :/

Jo, ten byl legendární, akorát jsem ho objevil až skoro v době kdy jsem přešel na Windows Phone.

Tehdy mě dost překvapily ty vlny když Apple uvedl první iPhone. Moc toho neuměl. Mimo jiné neměl GPS, neuměl připojit BT sluchátka ani BT GPS, neměl third party apps (ani SDK), neměl slušného PIM klienta atd. Z hlediska člověka, který léta používal Windows s GPS a mapami včetně live traffic, BT sluchátka, Outlook Mobile a řadu dalších vychytávek to bylo až komické. Ale iPhone se dal lépe ovládat prstem, na rozdíl od PocketPC/Windows CE/Mobile to nebylo "dodělej doma". Je to svým způsobem lekce: kvalita UI a absence bugů dovede často převážit nad funkcionalitou.

Mimochodem už ten první iPhone dostal AppStore, takže se z něj časem stal "chytrý telefon".

Zase měl použitelný browser...

Je pravda, že někteří uživatelé ho milovali. A zbytek ze srdce nenáviděl. Třeba u našich testerů byly zařízení s Windows Phone s velkým přehledem ta zdaleka nejméně oblíbená (a já se jim ani nedivím). Atokonto bych řekl, že rozhodně neumřel jen kvůli Googlu. Těch důvodů bylo víc.

Popravdě, je mi toho systému trochu líto. Určitě to nebyl OS pro mě, ale přijde mi, že pro běžněho uživatele to mělo skvěle navržené rozhraní. Ty dlaždice dávaly smysl, všechno bylo konzistentní, dobře integrované… Podobnou míru integrace zkoušela Nokie s Maemo a Palm Pre, a tady mi to přišlo docela dotažené. Když řeším mobil pro staršího člověka, Apple ani Android mi nepřijdou tak snadné na pochopení a vysvětlení jako tehdy WP.

Akcelerovat emulaci x86 samozřejmě smysl má, když většina aplikací je x86-only a nechcete prodávat zařízení jen geekům. AArch64 má užitečnou např bitovou masku pro zápis do registrů. Není třeba ANDovat a ORovat každou práci s registrem, když v x86 chcete zapsat jen do půlky registru. RISC-V to musel dostat jako extenzi, jinak by neměl na trhu šanci.

Jenže to pro binární rekompilaci nestačí. Musel byste do vygenerovaného kódu vkládat memory barriers pro synchronizaci mezi jádry CPU a po každé SIMD operací zkontrolovat výsledky. Takto emulátor (přesněji JIT binární rekompilace) nemusí tyto zpomalující série instrukcí vkládat do kódu, jen přepne 2 přepínače: 1) vypne jednu optimalizaci práce s RAM a 2) povolí speciální výsledky pro SIMD (FPU jednotky je umí, skalární instrukce FPU na ARMu je vrací).

Pro zajímavost, rozdíl výkonu s akcelerací a bez je běžně i 8x, v SIMD operacích i násobně pomalejší než toto. S hardwarovou akceleraci emulace x86 jste na 2/3 nativního výkonu, což vzhledem k dvojnásobku zpracovaných instrukcí za cykl je v pohodě a srovnává v x86 kódu s Intelem. Pozor, AArch64 instrukce jsou trochu "řidší" a ARM procesory mají menší frekvenci než typický x86. Zvláště u Intelu, kde lže s TDP až dvojnásobně a před novým mikrokódem utavil napájecí vodiče tranzistorů. Nicméně nový Qualcomm má dotáhnout na 5 GHz, tím pádem i tato výkonnostní výhoda x86 padá.

> Podle mě aby CPU mohl zvládnout AVX2 tak by potřeboval SVE2 s 256-bit délkou - pak by to bylo poměrně přímočaré.

Zapomínáte na to, že první implementace AVX2 byla v AMD "double-pump", tedy 256bit operace dělal na 128bit jednotkách. Stejně jako pak byla implementace AVX-512 v předchozí generaci AMD. Nebo když hodně do minulosti, tak Z80 v ZX Spektru byl 8bit CPU se 4bit ALU:
https://www.righto.com/2013/09/the-z-80-has-4-bit-alu-heres-how-it.html?m=1

> Kdo chce výkon na desktop/mobile segmentu a x86 tak použije AMD. AVX-512 je mimochodem to nejlepší na x86.

Záleží výkon v čem. Např v kompilaci kódu tichý a úsporný notebook s Qualcommem nebo Apple Silicon dotahuje na desktopový AMD. A to je dnes spousta věcí mimo hrubý výkon CPU, např GPU, video kodeky, NPU, ... Jinak AMD je výkonné a dobré, o tom se nehádám. Několik let se bude jíst OEM koláč Intelu, takže procesory Apple/AMD/Qualcomm nejdou proti sobě a je super, že si dnes uživatel může vybrat hned ze 4 výrobců výkonných procesorů. V podstatě pro výběr Intelu už musí mít člověk nějaký hodně velký důvod.

Ještě taková technická: AVX-512 instrukce protáhnou "více práce" skrz úzký dekodér instrukcí, pokud se jako na AMD a Intel dekódují za 1 cykl (čínský x86 dekóduje 2 cykly). Tímto v SIMD operacích je x86 srovnatelné s 8 instrukcemi za cykl. K tomu HT využije zbylé jednotky v jádře CPU pro vícevláknové kódy. Tedy AMD má pro tyto scénáře kompenzující řešení, narozdíl od Intelu, který v consumer segmentu nemá ani jedno.