Programmera i maskinkod?

Gör det första, maskinkod är inget universiellt "språk" utan beror helt och hållet på den aktuella processorns instruktionsformat, vissa processorer har ett ganska enkelt instruktionsformat som är enkelt att lära sig medan andra kan vara väldigt komplexa.

För det andra så finns det ingen direkt fördel med att programmera maskinkod då man lika gärna kan koda i assembler som sedan översätts direkt till maskinkod. En instruktion i assembler är oftast samma som som en instruktion i maskinkod.

Moderna kompilatorer genererar oftast väldigt bra kod, vilket gör det väldigt ineffektivt och tidsödande att programmera större program i t.ex. assembler. Oftast så tjänar man mer på att välja en bättre algoritm och datastruktur än att mikrooptimera med assembler.

Kan tilläggas att en kompilator är oftas bättre att optimera koden än om man skriver direkt i assembler.

Mnja, inte bättre. Men lika bra, i alla fall.

Det hänger väl mest på att få normala människor klarar (orkar, i alla fall) implementera större algoritmer effektivt i assembler?

Det finns många som kan maskinkod eller assembler som man också kallar det. Jag gick kurser i det när jag pluggade, och även om jag inte använt det mycket i praktiken så är det bra att kunna eftersom man då bättre förstår hur en dator fungerar och arbetar.

Maskinkod eller assembler är inget man använder idag när man skapar tillämpningar och spel för datorer. Maskinkod är det språk som CPUn förstår och alla instruktioner i program måste översättas till maskinkod innan processorn kan tolka dem. Detta kan ske vid olika tidpunkter. Se nedan.

Back in the day, när 8 bitar var tillräckligt var det dock vanligt att man skrev hela tillämpningar i maskinkod/assembler för att få bra prestanda.

Assembler används idag när man tex skriver lågnivårutiner för operativsystem, kompilatorer eller programmerar inbäddade system och FPGAer.

Man brukar dela in programmeringsspråk i kompilerande och interpreterande språk. Kompilerande språk som tex C/C++ översätts till maskinkod innan de körs. Detta kallas kompilering. Interpreterande språk översätts/interpreteras till maskinkod under tiden som programmet exekveras, vilket ger sämre prestanda eftersom CPUn måste översätta programmet till maskinkod samtidigt som programmet körs.

Indelningen i kompilerande och interpreterande språk är dock inte helt självklar. Java är tex ett slags mellanting. Java kompileras, men inte till maskinkod utan till sk byte-kod. Byte-koden översätts sedan till maskinkod av en JVM (Java Virtual Machine) samtidigt som programmet exekveras. Men byte-koden går snabbare att översätta, så man får bättre prestanda än ett rent interpreterande språk.

Om du börjar kolla här: The Hello World Collection
Så ser du ett Hello-world program skrivet i assembler för olika cpu:er m.m, tänk på att Hello World-program är bland det enklaste du kan koda och assembler är mycket enklare att skriva, läsa och förstå än vad maskinkod är, koda maskinkod tar väldigt lång tid, väldigt svårt att upptäcka fel och väldigt lätt att tappa bort sig.

Ja, "ren" maskinkod är det ingen som programmerar i utan man syftar i stort sett alltid på assemblerprogrammering när man pratar om maskinkodsprogrammering.

Skillnaden mellan assembler och maskinkod är att assembler är (något) enklare att läsa och skriva för en människa. Processorns instruktioner är egentligen en sifferkod, men i assembler representeras dessa vanligen av trebokstavsförkortningar, sk OP-koder. Tex JMP, MOV, BRK etc. Innan man kör sitt assemblerprogram så assemblerar man det till maskinkod och då översätts OP-koderna till ren maskinkod. Assemblering kan man säga är en enklare kompilering.

Ja, precis. Det man vinner på högnivåspråk är enkelhet och läsbarhet. Fördelen med lågnivåspråk är prestandan. Nackdelarna är att det är krångligare och lättare att göra fel. Programmen kan också bli svåra att ändra i vid behov.

För 15 år sen var det fortfarande ganska vanligt att man använde C/C++ i systemutveckling. Nu använder man nästan uteslutande högnivåspråk som tex Java.

Spel och vissa prestandakvärvande program är ett undantag. Där använder man fortfarande i stor utsträckning C/C++

Visst, en kunnig programmerare som har koll på datorarkitekturen och ska implementera en algoritm som är rätt så begränsad storlek kanske vet bättre än en optimerande kompilator. Men i stora program blir det så mycket assemblerkod att man tappar översikten över det och optimeringar blir ofta lokala fast en optimerande kompilator kanske ser det i det stora hela.

Sen kan man nämna att Suns/Oracles JVM har haft stöd för JIT (just in time) kompilering i över 10 år. Så när koden väl körs så är det inte översatt bytecode utan native. Det är inte heller ren JIT kompilering utan en hybrid där den översätter från bytekod bitvis men kompilerar till native för saker som används ofta.

Det är nuförtiden inte så viktigt att den genererade koden är superoptimal. Flaskhalsen är ändå minnet! Man ska skriva sin kod så man utnyttjar processorn cache så mycket som möjligt, och för det behöver man inte koda i assembler. Det kräver dock att man har bra koll på hur en cache funkar och hur det språk/system man använder utnyttjar minnet.

Sen är det ju så att man aldrig ska optimera i förtid. Att optimera en rutin för att censurera fula ord i ett foruminlägg är meningslöst eftersom det går vrålfort iaf.

Hur viktigt cachen och minnet är visas ganska fint i det här blogg-inlägget: Gallery of Processor Cache Effects
Han visar tex dom här 2 looparna:

int[] arr = new int[64 * 1024 * 1024];

// Loop 1
for (int i = 0; i < arr.Length; i++) arr[i] *= 3;

// Loop 2
for (int i = 0; i < arr.Length; i += 16) arr[i] *= 3;

Loop 2 körs lika fort som Loop 1 trots att den bara gör ~6% så mycket jobb(!) som den första loopen.

Dock är det värt att påpeka att det bara är i vissa fall som man ens behöver bry sig om cache-effekter, i många fall är det på en mycket högre/annorlunda nivå problemet ligger. Där jag jobbar kämpar vi ständigt med prestandan men skulle bli förvånad om någon ens tänkt tanken att skriva om något för att bättre utnyttja cpu-cachen.