Może dałoby się ten VMUL emulować niewielką liczbą dodatkowych instrukcji.
Pytanie czy warto. Nie sądzę, żeby gry na PS2 usiłowały sprawdzać obecność emulatora. Po prostu ich wtedy nie było ze względu na moc obliczeniową pecetów.
Te publiczne erraty nie zawierają żadnych istotnych szczegółów. Wszystko jest w praktyce maskowane przez inżynierów Intela na poziomie sterownika.
Ewentualnie developerów backendu do kompilatora.
Dziwne, że nikt nie powiązał błędnego zapisu z jednoczesnym użyciem kontrolera.
Ja kiedyś debugowałem błąd który objawiał się przywieszeniem kilku usług na może 5-10s w środku nocy. Kod był wielowątkowy, więc rozpatrywane były hipotezy obecności jakiegoś długiego locka, wyczerpania pamięci albo innego przeciążenia komputera.
Finalnie okazało się, że winna była maszyna wirtualna. Nie pamiętam teraz szczegółów, ale chodziło o jakąś próbę update’u z płytki CD, która wykonywała się regularnie o określonej porze.
Kosztowało to kilka godzin analizy logów i kodu, do momentu aż zorientowałem się, że zatrzymuje się cały system, włącznie z kernelem.
Może dałoby się ten VMUL emulować niewielką liczbą dodatkowych instrukcji.
Pytanie czy warto. Nie sądzę, żeby gry na PS2 usiłowały sprawdzać obecność emulatora. Po prostu ich wtedy nie było ze względu na moc obliczeniową pecetów.
Artykuły o przeciwdziałaniu twórcom emulacji zdarzają się co jakiś czas. Zawsze to brzmi bardziej sensacyjnie niż: https://www.os2museum.com/wp/learn-something-old-every-day-part-x-the-vga-attribute-controller-is-weird/
Jeśli takie rzeczy występowały w latach 80, to ciekawe jakie niedoróbki trzeba maskować w dzisiejszym sprzęcie, który jest znacznie bardziej złożony.
Jeżeli pytasz o błędy w x86, to tutaj masz dzieła zebrane https://elixir.bootlin.com/linux/v6.9.5/source/arch/x86/kernel/cpu/bugs.c.
Tutaj inna nierówna walka z błędem w układzie Intela https://bugzilla.kernel.org/show_bug.cgi?id=109051#c752
Czytałeś o 386 z symbolem Sigma?
Dzisiaj pewnie wystarczy otworzyć erratę do dokumentacji jakiegoś chipsetu. https://edc.intel.com/content/www/jp/ja/design/ipla/software-development-platforms/client/platforms/alder-lake-desktop/intel-600-series-chipset-family-platform-controller-hub-pch-specification-upd/004/errata-details/
https://edc.intel.com/content/www/jp/ja/secure/design/confidential/products-and-solutions/processors-and-chipsets/tiger-lake/11th-generation-intel-core-processor-family-specification-update/errata-details/
Nie słyszałem o tej Sigmie.
Te publiczne erraty nie zawierają żadnych istotnych szczegółów. Wszystko jest w praktyce maskowane przez inżynierów Intela na poziomie sterownika.
Ewentualnie developerów backendu do kompilatora.
W każdym razie błędy są do dzisiaj. Tylko dzisiaj łatwiej z nimi żyć. Dzięki dużej ilości warstw elastycznego kodu po drodze do sprzętu.
Jeszcze jedna historia. Nie do końca na temat. https://www.gamedeveloper.com/programming/my-hardest-bug-ever#close-modal
Dziwne, że nikt nie powiązał błędnego zapisu z jednoczesnym użyciem kontrolera.
Ja kiedyś debugowałem błąd który objawiał się przywieszeniem kilku usług na może 5-10s w środku nocy. Kod był wielowątkowy, więc rozpatrywane były hipotezy obecności jakiegoś długiego locka, wyczerpania pamięci albo innego przeciążenia komputera.
Finalnie okazało się, że winna była maszyna wirtualna. Nie pamiętam teraz szczegółów, ale chodziło o jakąś próbę update’u z płytki CD, która wykonywała się regularnie o określonej porze.
Kosztowało to kilka godzin analizy logów i kodu, do momentu aż zorientowałem się, że zatrzymuje się cały system, włącznie z kernelem.
Warto polecić jeszcze dramę o tym jak Geohot próbował napisać Tinygrad na Radeona.