Názory k článku
Linus Torvalds je proti jádru Big Endian pro RISC-V

A má pravdu - není žádný důvod aby to někdo dělal. V praxi to nikdo stejně nechce.

Jak se někdo vůbec odváží zmínit, co nechce NIKDO, je to přinejmenším podezřelé a rozhodně ne důvěryhodné.

Kdybyste si přečetl LKLM a ne jen zprávičku, tak zjistíte, že RISC-V s BE v současné době není v linux jádře podporována. Rozšíření RISC-V s BE je aktuálně zanedbatelné a zavedení podpory do jádra zkomplikuje situaci všem. Takže proč se do toho pouštět?

Pokud to chcete jako akademický projekt - prosím. Udržujte si vlastní strom, kde si budete řešit vzniklé komplikace, ale nezatěžujte s tím ostatní. Pokud to chcete pro zrychlení zpracování network packetů, tak použijte LE a rozšíření Zbb.

Linus jasně řekl, že pokud by RISC-V BE významně rozšířilo, tak pak má smysl to do jádra přidat. Ale není důvod, aby linux tuto "hovadinu" podporoval preventivně.

Já se v těchto nízkoúrovňových oblastech nepohybuji, ale trochu mě překvapuje, že se někde v nových architekturách ten BE ještě vyskytuje, když je ten LE "tak" výhodný (neironizuji, vytušil jsem z diskuse, že to tak je).
Aktuálně probíhá vymýcení obsoletního BE kódu v Blendru, protože už to žádná architektura nepodporuje, nebo zároveň umí i LE. Aha, teď mi dochází "žádná, kam je Blender portovaný". Ale stejně. Má tedy BE výhody, či přednosti, proč jej nadále v hardware implementovat?

Podezřelý je tydýt, který se chová, jako by právě spadl z višně. To se prostě tak říká.

"Se to tak říká" je super. Ostatní mlátí černochy, se to tak dělá prostě, no.

A kdo používá ARM-BE?

BE je historie. Každá mainstream architektura je dnes LE ne kvůli Intelu, ale kvůli tomu, že s LE je prostě pohodlnější pracovat. A takový SIMD v BE, to je něco...

Takže ano, odvážím se to zmínit - RISC-V BE je jen akademická záležitost, kterou v praxi nikdo nepotřebuje. A Linus má pravdu, že nemá cenu prasit jádro s něčím, co vlastně nikdo nechce.

Fork je ale vždycky možnost, kterou nikdo nikomu nebere.

3. 10. 2025, 14:29 editováno autorem komentáře

Pohodlnejsi pracovat? V cem?


section .data
num dd 0x12345678 ; 32-bit integer stored in little endian
section .text
global _start
_start:
mov eax, [num] ; load 0x12345678 into eax
add eax, 1 ; add 1
mov [num], eax ; store result back
; now num = 0x12345679, memory = 79 56 34 12

vs

.data
num: .long 0x12345678 # stored as 12 34 56 78 in memory
.text
.globl _start
_start:
lwz 3, num(0) # load word into register r3
addi 3, 3, 1 # add immediate 1
stw 3, num(0) # store it back
# num now = 0x12345679, memory = 12 34 56 79


Pisu jednou za cas neco v asm (pro sebe) a je mi fuk jestli je to le/be.

Hadej co se stane, kdyz budes zpracovavat neco, co se nevleze najednou do registru. Nemusi to byt rovnou BigNum. Pointery budou pokazde ukazovat na nejnizsi adresu. V LE muzes okamzite zacit scitat (odcitat) dve cisla na ktere mas pointery.

Můžeš nějak vysvětlit, o co ti v tom příkladu vůbec jde? Navíc v tom prvním stačí napsat místo 3 řádků prostě:

add [num], 1

To, jak jsou v LE data uložené v paměti přece každý ví, na to není potřeba příklad v asm.

Změňme to - zpracovávám string v SIMD a chci najít třeba nějaký znak. V x86 by tělo cyklu mohlo vypadat nějak takto:


main_loop:
vmovdqa ymm1, [rax] // Load 32 bytes
vcmpeqb ymm0, ymm1, ymm15 // Compare with broadcasted byte in ymm15
vpmovmskb eax, ymm0 // Move the result of 32 byte comparisons into eax
test eax, eax
jnz found
// Advance and pointer check
add rax, 32 // Advance input pointer
cmp rax, rdx // Compare whether to iterate over
jne main_loop
// Tail condition:
tail:
// Have a match!
found:
tzcnt ebx, eax ; // The first byte that matched the byte in ymm15


Přemýšlet v LE je prostě pohodlnější, data se načtou přesně jak je potřeba, a toto byl jen jednoduchý příklad co má pár řádků. Portovat třeba nějaký SIMD kód jen z AArch64 na AArch64-BE je mission impossible, pokud to není jen pár řádků. No a to je důvod proč AArch64-BE se nikde nějak nepoužívá - nedává to smysl.

BTW je tady vůbec možné vložit normálně kód, co má i nějaký indent a prázdné řádky? Toto je úplně zprasené.

Nevím, mě na to asi chybí vhled. Naposledy jsem se setkal s BE (domnívám se) u Amigy na Motorole 68000/68020. A "tenkrát" ti to přišlo naprosto super, přirozený (lidský) zápis čísla, zatímco zpřeházené pořadí bajtů u "Intelu" mi přišlo jako magořina. Hmm. Zase jsem v tom assembleru či strojáku nikdy nic nedělal, aby mě to jinak trápilo. Vzhledem k tomu, co čtu teď v diskusích a že i ty procesory, které byly na BE založeny časem uměly oboje, nebo přešly na LE, tak to z má asi jisté výhody. :)

Pokud někdo v běžné diskusi napíše „nikdo“ nebo „všichni“, myslí tím „nikdo/všichni až na zanedbatelné výjimky“. Protože než napsal ten komentář, určitě nedělal celosvětový průzkum, aby zjistil, že je dohromady osm uživatelů, kteří by to chtěli použít.

(V mém komentáři je to 8 také vymyšlené číslo. Také jsem to nezkoumal.)

4. 10. 2025, 08:38 editováno autorem komentáře

"Skoro nikdo" nebo "pár lidí" to řeší, ale jeden musí umět jazyk, to uznávám.

„Skoro nikdo“ nebo „pár lidí“ ovšem znamená něco jiného. Znamená to, že těch lidí je sice málo, ale pořád je potřeba brát je v úvahu. Když napíšete „nikdo“, jsou případné výjimky nedůležité.

Cajk, ale nepíše se to tak důrazně celé velkými písmeny. To pak vypadá až moc direktivně z moci osobního přesvědčení, nikoli jako synonymum pro "statisticky zanedbatelná menšina". :)

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 :)