Názory k článku
Linus Torvalds je proti jádru Big Endian pro RISC-V
-
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? -
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 79Pisu jednou za cas neco v asm (pro sebe) a je mi fuk jestli je to le/be.
-
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 ymm15Př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. :)
-
Filip JirsákStříbrný podporovatelPokud 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
-
Filip JirsákStříbrný podporovatel
„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é.
-
FíkZlatý podporovatelJe 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.
-
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.
-
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.
-
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. -
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 :)
