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]

[vrit]

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.

Tak jakto že The C Programming Language od Kernighana a Ritchieho z roku 1978 zmiňuje preprocesor?

Abych dostal to makro ENDIANESS tak musím mít někde mrtě platformně závislé logiky.

To je prosím celá mrtě logika, která je potřeba pro detekci endianity buildtoolem - ten checkne návratový kód.

Kód: [Vybrat]

#include <stdint.h>

int main(void)
{
    uint32_t x = 1;
    uint8_t *p = (uint8_t  *)&x;

    return p[0] == 1;
}
Ano na nějakých exotických systémech to asi i tak selže, ale umí toto nějaký jazyk lépe? V praxi na jakémkoliv moderním systému to bude fungovat.

Další věc je, že endianita se dá kompletně odstínit pomocí OR a posuvů, takový kód je pak na endianitě nezávislý.

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.

Linux je nejpřenositelnější OS jaký existuje No a nemyslím si že používají GCC kvůli tomu že by C nebylo přenositelné. Inline assembler je spíše praktická věc pro OS kód. Různé builtin funkce jsou spíše optimalizační techniky. Makro typeof zase umožňuje generičtější kód, což jenom šetří psaní... dalo by se bez toho všeho obejít. Které věci z GCC dialektu jsou striktně kvůli přenositelnosti bez kterých by se nedalo obejít?

[novomente]

Jako malý kluk jsem měl možnost pracovat na Commodore 64. Programoval jsem většinou v BASICu. Zkoušel jsem i monitor pro strojové instrukce, ale neboť jsem neměl žádnou literaturu k programování v assembleru, tak jsem v podstatě nic nenaprogramoval.

Před pár lety jsem v rámci mého soukromého studia tu literaturu našel a tak jsem si v assembleru naprogramoval jednoduchou hru. Samotné programování mi zabralo asi rok (včetně grafiky, hudby, a SFX). Čtyřikrát jsem to celé přepisoval, neboť jsem se ztrácel v kódu. Napočtvrté jsem už si stanovil vlastní styl, a tak se to nakonec na počtvrté podařilo.

Hra funguje, grafika, font, hudba a zvuky jsou vcelku vydařené. Ale nejvíce si vážím toho, že jsem ten svůj první a zároveň poslední velký program v ASM dotáhl do úplného konce. Bylo to a stále je to pro mě velkým přínosem. Jsem s tou prací spokojen a věřím, že ta zkušenost mi stála za ten rok programování. 

nm

[Pavel Tišnovský]

Jako malý kluk jsem měl možnost pracovat na Commodore 64. Programoval jsem většinou v BASICu. Zkoušel jsem i monitor pro strojové instrukce, ale neboť jsem neměl žádnou literaturu k programování v assembleru, tak jsem v podstatě nic nenaprogramoval.

Před pár lety jsem v rámci mého soukromého studia tu literaturu našel a tak jsem si v assembleru naprogramoval jednoduchou hru. Samotné programování mi zabralo asi rok (včetně grafiky, hudby, a SFX). Čtyřikrát jsem to celé přepisoval, neboť jsem se ztrácel v kódu. Napočtvrté jsem už si stanovil vlastní styl, a tak se to nakonec na počtvrté podařilo.

Hra funguje, grafika, font, hudba a zvuky jsou vcelku vydařené. Ale nejvíce si vážím toho, že jsem ten svůj první a zároveň poslední velký program v ASM dotáhl do úplného konce. Bylo to a stále je to pro mě velkým přínosem. Jsem s tou prací spokojen a věřím, že ta zkušenost mi stála za ten rok programování. 

nm

Gratulace (jako vážně!)