Přemýšlel jsem přesně o tom samém. Z hlavy mě napadají tak maximálně 2-3 příklady, Leon2/3 (ESA cpu pro vesmírné projekty, vlastně ani netuším zda se někdy fyzicky realizoval), pak IBM Z-System, ale tam zase netuším proč by na tom někdo chtěl provozovat Linux místo Z/OS a jako poslední mě napadá, že i moderní ARM se dá nabootovat jako Big-Endian, ale opět mi chybí důvod, proč by to někdo dělal (někde jsem viděl návod na Nvidia Jetson)
... a jako poslední mě napadá, že i moderní ARM se dá nabootovat jako Big-Endian, ale opět mi chybí důvod, proč by to někdo dělal (někde jsem viděl návod na Nvidia Jetson)
Duvod?
Nemela by sitarina bezet na BE strojich lepe, kdyz vetsina, ne-li vsechny sitove vrstvy maji struktury v BE formatu?
Jako ty ntoh()/hton() swapy v modernich cpu zaplni urcite uops bubliny, ze to neni prace navic - ale stejne.. treba by to melo mensi spotrebu?
Diky za tip na BE Jetson (a dalsim k obecnemu aarch64).. takovou divocinu musim zkusit :)
BSWAP instrukce už byla na 486.
PowerPC umí přes nativně BE datový segment namapovat alias v little endianu.
Z jednoho segmentu se zapisuje a čte v BE formátu a skrz alias v LE formátu, konverzi reší HW transparentně a nic navíc to nestojí.
ARM má instrukci REV.
MIPS má WSBH.
SPARC žádnou podporu pro LE neměl, bswap se musel rozepsat na shifty.
Největší brzdou na RISC architekturách jsou nezarovnané struktury, to je horší jak BE/LE.
Tak Leonů a dovozených procesorů ve vesmíru léta hodně. Přehled procesorů
https://www.gaisler.com/index.php/products/processorsPřehled součástek na křemíku
https://www.gaisler.com/index.php/products/componentsZajímavostí je pak osmijádrový GR765, kde se pinem na začátku přepíná, jestli naběhne jako Noel-V (RISC-V) nebo LEON5FT (SPARC)
https://www.gaisler.com/index.php/products/components/gr765Jinak mnoho implementací bude i na FPGA, ale ty téměř jistě nemá smysl provozovat s GNU/Linuxem. Bude to pomalé. I ty na křemíku budou většinou s RTOS RTEMS https://www.rtems.org/.
Ale určitě má být kód otestovaný. CAN FD driver k CTU CAN FD IP core jsem před posláním do mainline testoval v buildech x86_64, ARM (několik) a MIPS v QEMU s využitím mnou spravovaného QEMU CAN subsytému. Ano, dalo to trochu práce najít kombinaci MIPS big-endian architektury rozumně podporovanou QEMU až po PCI a pak i nějakou kontrolu naší emulace CTU CAN FD přes PCI na big-endian systému. Ale file-system driver je jednodušší, tam není potřeba podpora HW, stačí třeba i jen soubor v ramdisku použít přes loop a vše lze otestovat, tedy do nějaké rozumné velikosti FS. Ale ve velkém to jde na x86, protunelovat velký image i do MIPS, ARM atd ale také nebude problém.
Takže problém bude opeavdu asi v přístupu autora a je otázka, jestli takto spravovanému FS svěřit svoje data.
Existuji u nas v CZE i na SVK zakaznici, kteri IBM Power9 normalne pouzivaji s aktualnim AIXem 7.3 a bezi na nich napr. Informix Database nebo 4GL programy apod.
Zadna anomalie to neni, jsou to extra vykonne a hlavne stabilni servery spolecne s PowerVM virtualizaci (VIOS).
Jeden takovy (nejsilnejsi) spravuji, ma 128 vCPUs, 750 GB RAM, par desitek TBs diskove kapacity...
Kazdopadne dle AI uz od Power8 umi tyto masiny i LittleEndian (pro lepsi kompatibilitu s okolnim infra).
Pro zajímavost, PowerPC mělo podporu Little/Big Endian, ale POWER ne, ten až o dost později, jak vám řekla AI. Proto byl problém s PowerPC G5, který už byl z nedostatku lidí, financí a nálady odvozen od serverového POWER, a ten v té době little endian neuměl. Trvalo dost dlouho, než lidi zprovoznili emulaci x86. Myslím, že i s několikanásobně větším výkonem G5 oproti G4 to nejelo rychleji. Já mám doma iBook G4 s Microsoft VirtualPC, a v něm Windows 2000 a 98, a první PowerPC (šest set něco) s Little Endian Windows NT. Nemám žádnou G5, abych to porovnal. To jen pro info, že výše Marvin píše, že je PowerPC je LE-přátelská architektura (neplatí pro G5).
No nejen s Linuxem, ale ještě s polední verzí jádra a s divočinou jako bcachefs, aby je takovýhle problém poškodil.
Nicméně Linusovi jde o princip, pokud jsem to pochopil správně. Teď nad tím mávne rukou, a za půl roku z tohohle přístupu bude kernel panic na polovině používaných zařízení.
8. 10. 2024, 07:44 editováno autorem komentáře