Vlákno názorů k článku
Linus Torvalds je proti jádru Big Endian pro RISC-V od Vantomas - Není potom rozdíl i v tom, jak jsou...

Není potom rozdíl i v tom, jak jsou uložené data/soubory na disku/filesystému? Mám pocit, že jsem někde v nějakém blogu/diskusi o starých strojích narazil na to, že někdo zkoušel zachránit data ze starého HDD a musel to nejprve přečíst v RAW a pak otočit pořadí, aby z toho mohl začít tahat data.

Je to jen o paměti. Jak jsou uložena data na disku záleží na FS a nemusí to souhlasit s uložením v paměti. Například ext4:

All fields in ext4 are written to disk in little-endian order. HOWEVER, all fields in jbd2 (the journal) are written to disk in big-endian order.

A proč je žurnál BE?

Hmm, není původně z jfs?

BTW ale nějaká levná (SoCka) BE architektura by se mi hodila, čistě z důvodu si ověřit, jestli moje prasárny jsou přenositelné tak, jak si myslím, nebo ne. Takže škoda, že BE RISCV nebude. :(

Pokud to nelze sehnat fyzicky, tak se podivej na nejakou VM v QEMU.

Namatkou z USE flags vidim: aarch64_be , ppc, ppc64, nebo obojetne - mips/mips64, sparc/sparc64, alpha.

Btw RV-BE tam neni, coz dela hezky obrazek o tom, jak moc to je relevantni :)

Ja bych se do takovych pokusu zjistovani jak dobre je kod portovatelnej poustel az kdyz budes mit sadu testu - aby slo automatizovane zjistit zda to vykazuje vady nebo nikoliv, pak to opravit a pretestovat.

5. 10. 2025, 20:59 editováno autorem komentáře

Jen upozorním, že nejde jen o to jestli to kompiluje a projdou testy. Pokud aplikace zapisuje či posílá nějaká data, tak často prostě vyblinká nějakou binární strukturu. A ta používá LE nebo BE, podle toho kde to běží. Pokud to není ošetřené, tak jsou například soubory uložené při běhu na BE HW nepoužitelné na LE HW.

V tomhle přináší serializace například do XML výhodu. Tedy vyjma toho že je to XML obrovské, serializace a deserializace je výpočetně náročná, a aplikace stejně do toho XML často s klidem zapíšou sem tam nějaký base64 blob, který vede zpátky na problém s endianness.

Asi jak to historicky navrhli, tak už to zůstalo.

To zalezi co je to za FS - a zda ma definovanou endianitu svych struktur nebo ne. MS FAT varianty jsou vzdy LE, a NTFS snad taky.

Obecne formaty souboru maji definovanou jednu endianitu, podle platformy na ktere vznikly a bezi.

Napr. MOV (a MP4, obecne ISO BMFF) kontejner je vzdy BE, protoze je to dilo applu.

Pak existuje TIFF, ktery je obojetny, podle hlavicky muze byt LE i BE (ale vetsina TIFF, DNG a RAW souboru je znova BE).

Myslim ze WAV audio je pak LE, atd.

Všechno staré je BE a všechno nové LE :)

A nekdy to pohlavi nejde ani urcit :D

(prikladem budiz architektury co postradaji moznost nezarovnaneho pristup do pameti - takze vlastne se na ty bajty nemate jak dostat, je to vzdy 32 ci 64 bit a nazdar).

A pak jsme chvili zapasili taky s PCI / PCIe, nekdy ty standardy jsou velice kreativni v dokumentaci - a je to na styl pripojovani USB.. zkusite tak, zkusite naopak, a pak pochopite ze prvni bylo spravny :D

AFAIK to závisí i na SW.
- Při vytváření backupu ve Firebird (SQL) se pro přenos záloh mezi různými systémy požívá flag "-t" – transportable. Předpokládám, že je to kvůli endianitě ve vytvořeném výstupním backupu.
- Texťáky v UTF-8 mívají na začátku 3bajtový header určující endianitu kódování.
- V tuto chvíli mě nic jiného nenapadá, ale to neznamená, že by se už nic nenašlo. Nicméně sdělení mělo znamenat, že i u toho FS to může být problematické. Nečekal bych ale v aktuálních FS z aktuálních OS nějaké zrady typu na CPU XY má ten FS BE a na jiném LE.

Zrovna UTF-8 na endianitu nehraje ... je to 8 bitovy transport totiz :D

BOM (byte order mark) se nachazi hlavne v UTF-16 (a UTF-32) souborech, aby se rozlisilo UTF16LE a UTF16BE.

Pouziti v UTF-8 jenom pridava explicitnejsi indikaci ze jde o UTF-8 enkodovanej obsah.

I když je je BOM (Byte Order Mark) dobrá myšlenka, moc se neujal, a většina SW ho bere prostě jako znaky, ať už v UTF-16, UTF-32 nebo UTF-8. Snad vyjma textových souborů jsem se s ním nikde reálně nesetkal. A například v konfiguráku je BOM typicky interpretován jako součást prvního řádku. Pokud je na něm nějaké nastavení, tak jste o něj právě přišel.

Netisknutelné znaky jsou vůbec skvělé. Například dialog detailu certifikátu ve Windows ještě před pár lety při zkopírování hodnoty certificate fingerprintu (ve Windows zvaném thumbprint) do kopírované hodnoty velmi "chytře" přidal i nějaké netisknutelné znaky. Když hodnotu člověk použije v konfiguráku, tak to v editoru vizuálně není vidět, a aplikace pak certifikát nenajde. V logu skončí hláška o tom, že certifikát nelze najít podle thumbprintu toho a toho, kde ty netištitelné znaky jsou, ale pochopitelně opět nejsou vidět. Hledat takové problémy je potom fakt lahůdka. Jen dosti specifický typ lidí si konfigurák zkontroluje v hex view :)