Rozdíl mezi ASM a strojovým kódem

[Vít Šesták (v6ak)]

Případně přenositelnost, kdy stejná instrukce na jiném procesoru má jiný kod.

Teoreticky ano, prakticky o tom silně pochybuju, nebo by muselo jít o dost omezený kousek kódu.

Nemá moc smysl dělat procesor se stejnou instrukční sadou, ale jinými opcodes. Když už stejná instrukční sada, tak lze docela čekat i stejné opcodes.

A když bude instrukční sada jiná, čekám, že u netriviálního kódu bude příliš odlišná na to, aby šlo napsat stejný assembly code a jen to přeložit jiným assemblerem.

Pokud oba procesory budou mít aspoň podobnou základní koncepci, možná to půjde u nějakého triviálního kódu. Hádám, že to typicky nebude kód, u kterého bude dobrý důvod použít asm. Tady se spíš v praxi uplatní relativně vyšší jazyk (C/Rust/Fortran/…) a dnes celkem dobře zvládnuté optimalizace v kompilátoru.

EDIT: Možná je realističtější opačný scénář: máme dvě rodiny CPU se stejnou (či dostatečně podobnou) instrukční sadou, ale budeme v asm mít dvě různé verze kódu. Sice obě budou fungovat na obou CPU, ale dvě různé verze budeme mít kvůli výkonu.

[Reklama]

[Jiří Havel]

A jak souvisí překladač, platforma, verze a nebo název makra s tím jestli je jazyk přenositelný? Toto makro má nakonfigurovat build systém a předat ho překladači.

V režii jazyka už pak je jenom podmíňěná kompilace na tu nebo onu variantu.
...

Tu podmíněnou kompilaci ale nedělá jazyk C ale C preprocesor. Je to separátní tool, který ani nerozumí kompletní syntaxi C a používá se i pro jiné jazyky. Integrace preprocesoru do překladače proběhla až relativně nedávno, protože to oddělení mělo nepříjemné důsledky na použitelnost.

Ve chvíli, kdy build systém chystá makra pro preprocesor, tak je přenositelný úplně každý jazyk. Abych dostal to makro ENDIANESS tak musím mít někde mrtě platformně závislé logiky. Protože sám jazyk C v tom pro mně neudělá ani ň.

Btw, drtivá většina C kódu není přenositelná, ale je psaná v nějakém platformně závislém dialektu. Je to proto, že v přenositelné podmnožině C chybí naprosto zásadní věci. Např linux není psaný v C ale v GCC dialektu a při portování do clangu se do něj ten GCC dialekt přidal.

[Jiří Havel]

Případně přenositelnost, kdy stejná instrukce na jiném procesoru má jiný kod.

Teoreticky ano, prakticky o tom silně pochybuju, nebo by muselo jít o dost omezený kousek kódu.

Nemá moc smysl dělat procesor se stejnou instrukční sadou, ale jinými opcodes. Když už stejná instrukční sada, tak lze docela čekat i stejné opcodes.

Čistě teoreticky by se tady dala vytáhnout rodina x86 procesorů. Kdy stejné instrukce assembleru můžou být zakódované pomocí mnoha různých opkódů. A staré procesory umí některé, které už nové neumí a naopak.
Ale prakticky se pořád mluví o x86 instrukční sadě.

[a6b]

Případně přenositelnost, kdy stejná instrukce na jiném procesoru má jiný kod.

Teoreticky ano, prakticky o tom silně pochybuju, nebo by muselo jít o dost omezený kousek kódu.

Nemá moc smysl dělat procesor se stejnou instrukční sadou, ale jinými opcodes. Když už stejná instrukční sada, tak lze docela čekat i stejné opcodes.

Čistě teoreticky by se tady dala vytáhnout rodina x86 procesorů. Kdy stejné instrukce assembleru můžou být zakódované pomocí mnoha různých opkódů. A staré procesory umí některé, které už nové neumí a naopak.
Ale prakticky se pořád mluví o x86 instrukční sadě.

to mi pripomelo kompilator, ktery generuje pouze move instrukce.

https://github.com/xoreaxeaxeax/movfuscator

[Jiří Havel]

to mi pripomelo kompilator, ktery generuje pouze move instrukce.

https://github.com/xoreaxeaxeax/movfuscator

Ten "single instruction" nadpis otvírá zajímavou teoretickou otázku, "Co je to vlastně ta 1 instrukce?"

Protože ten mov má hromadu variant, co dělají i docela odlišné věci. Už jenom "load" a "store" jsou tak odlišné věci, že pro to mají některé architektury různé instrukce.

[Reklama]