Vlákno názorů k článku
S opravou chyby AMD Zen 1 při dělení nulou to není tak jednoduché, jak se dříve zdálo od cc - Toto má líp vyřešené ARM - při dělení...

Toto má líp vyřešené ARM - při dělení 0 je výsledek 0 - jednoduché, nezneužitelné.

Super, takze namiesto toho aby sa korektne vyhodila nejaka chyba tak isto ako sa deje v matematike - je to nedefinovany stav. Tak sa radsej vyhodi konkretne cislo - 0. Preco sa nevyhodi Int32.Min, alebo Max, alebo Int64.Min, alebo Max? Su v ARMe skryte dalsie taketo matematicke omyly s ktorymi treba ratat pri pisani kodu?

To je ale úplně jedno. Z hlediska moderního návrhu CPU je nejlepší minimalizovat výjimky tohoto typu. FPU exceptions už taky nikdo nepoužívá, protože tu máme SIMD, maskování a další věci...

Pokud dělám VM, tak ta podmínka tam stejně musí být, protože odchytávat signál kvůli dělení nikdo nechce. A pokud používám jazyk jako C, kde to bude undefined behavior, tak stačí použít sanitizer nebo do kódu přidat assert.

V CPU tuto funkci prostě už nikdo nepotřebuje, je to naprosto zbytečné.

Takze o tom, co dela CPU a SW nemas paru ze? Ono se totiz na deleni nulo muze snadno dojit ... delenim nenulou. Jednoduse proto, ze nekde neco pretece. A ten tvuj uplne neskodnej vysledek ... tedy nula = vse bezi dal, jen nekde neco (treba jaderna elektrarna) vybuchne.

A vazeni, presne takto dnes vypadaji ti, co se zovou programatory. Vubec netusi co cini.

Jako že v jaderné elektrárně se budou spoláhat na to, že CPU zachytí integer division by zero? CPU vygeneruje exception, a co pak? Mohl bys to tu rozepsat, když tomu tak rozumíš?

Nevim kolik toho v životě udělals ty, ale já ti garantuju, že zrovna u těchto věcí ty kontroly budou úplně všude a k tomu dělení nulou nikdy nedojde právě kvůli tomu, že ty hodnoty budou zkontrolované 10x, a obě!

Dělení 0 je undefined behavior - žádný C/C++ kód se nemůže spoléhat na to, co CPU udělá, protože každá architektura má vlastní chování. Portabilní kód si vstupy prostě musí kontrolovat a ne čekat na to, že CPU něco udělá v takovém případě. Ve většině SW když k tomuto dojde, tak ten proces končí.

Jedno to teda rozhodne neni.

Ak si vrstva podomnou (to jest HW) stvara psie kusy o ktorych ja nemam paru pretoze logicky ocakavam nieco ine (tu to bude exception), rovnako ako to ocakava 99.999% programatorov.
To ze niekto bol lenivy to urobit naporiadok aj ked komplikovane, a rozhodol sa s tym radsej vym**at tym ze vrati nezmysel (tu je to ta nula), tak to urcite nie som nadseny z takej architektury.

To sme opet v dobe kedy napr intel mal FDIV bug, ked vracal pri deleni floatov zle vysledky (resp prvych par cislic bolo spravnych ale potom presnost vysledku isla do kopru).
Az z toho vznikol vtedy vtip:
Je sutaz kde dva procesory, Intel a AMD sutazia kto je lepsi. Rozhodca povie otazku - kolko je 2+2?
Intel v tom okamihu bleskurychle zahlasi 5. AMD o moment neskor odveti 4, a nasledne hovori intelu - vies ze 2+2 ma byt 4 a nie 5, tvoja odpoved je nespravna. Intel odveti: To je mozno pravda ze som povedal zly vysledok, ale ta rychlost!
No, a ak takto vyzera ten preslaveny ARM, tak to nie dakujem, zostanem radsej u X86/64.

Mám pocit, že hodně lidí v této diskuzi nechápe rozdíl mezi HW a programovacím jazykem. Pokud používáš C++, tak dělení nulou je UB. Pokud jiný jazyk, který tu operaci specifikuje, tak se můžeš spolehnout na kontroly, které tam přidá compiler toho jazyka.

Tím bych tu diskuzi ukončil, nemám čas se hádat s lidma, co toto nechápou a navíc tu řešit nějaké hloupé paralely s jinou chybou, která s tímto vůbec nesouvisí.

BTW jen pro doplnění: ARM a RISC-V jdou úplně stejnou cestou, doporučil bych si o tom něco přečíst.

Nastesti matematika a IT jsou dva oddelene svety.
Co je matematicky spravne nemusi byt v IT optimalni a naopak.
Tohle by mel nekdo studentum vysvetlit uz na zacatku studia jinak ta hovna budou tahat cely zivot do kodu.