( bzt | 2024. 03. 12., k – 13:03 )

A Merge Request-et már ott a repo-ban.

Köszönöm, máris hozzáadom!

A legtöbb idő itt egyébként arra ment el, hogyan lehet bare metal bináris output-ot gyártani,

Erre elvileg nincs szükség, a betöltő pont azért van. Bármilyen szabályos ELF vagy PE/COFF betölthető velük, nem kell alacsony szintű raw binary fájlokkal vacakolni, meg futásidőben valós módban betölteni a fennmaradó részt.

Megjegyzés a peremfeltételekhez: az iretq hívást így kezelni, hogy a saját interrupt handlerből kell meghívni függvényként azt, ami majd valahogy kiléptet az egész interrupt handler-ből, ez szerintem szívás.

Tessék az AMD és Intel mérnököknél panaszkodni, ne nálam. Így működik a CPU, ezt nem tudod megkerülni. Még Assembly-ben is külön speciális utasítás van erre (aminek a neve történetesen "iretq").

nem igazán tudod megtippelni, hogy mekkora lesz a stack frame

Dehogyisnem! Pontosan tudod, hogy a stackframe egyetlen változót helyez a verembe (a korábbi stackframe tetejét), és ez nyelv valamint fordító független, illetve a függvényhívás CALL utasítás mégegyet, de ez megint nyelv és fordító független.

Itt kb. jósolni kell, hogy mi az a szám, amivel nem fagy le az egész gép. És ez lehet, hogy egy másik compiler verziónál már más lesz.

Egy C program ezen a CPU specifikus működésen túl nem is nyúl a veremhez (amennyiben a függvény nem tartalmaz lokális változót).

Pont ez volt a verseny egyik célja, hogy az ilyenekre, amire itt panaszkodsz, rávilágítson: a Rust nem egy jövőbiztos megoldás, a C-vel ellentétben nincs semmi garancia arra, hogy 5 év múlva is működőképes programot fog fordítani! Simán lehet, hogy addig vagy 10x átírják az ABI-ját, ami úgy fogja eltörni a kódodat, hogy közben nem változik a forrásod egy bitet se!