Maskinnära kod kommer alltid behövs, men mängden assembler som behövs (eller ens är önskvärd) i ett modernt OS är försvinnande liten.
Finns överhuvudtaget inget anledning alls att ett kommando som MORE ska ha en enda rad assembler, i DOS var detta tydligen helt skrivet i assembler.
Den stora lärdomen man kan dra av detta är: detta är ett väldigt bra exempel på varför det historiskt var sådan brutal barriär att byta CPU-arkitektur för ett OS. Även de saker som är skriva i C, t.ex. ATTRIB gör ju direkta referens till CPU-register (vilket man kan göra i C, men ytterst sällan en vettig idé utanför mycket specifika fall).
Det som hänt sedan 80-talet fram till nu är att dels har CPUs mikroarkitektur blivit långt mer komplicerade, ihop med att kompilatorer blivit långt bättre. Även de som fortfarande kan assembler kommer i väldigt få fall kunna skriva kod som presterar bättre än vad en kompilator spottar ur sig på bråkdelen av tiden. Framförallt inte om man vill ha lite bredare stöd över många CPU-modeller.
Idag är inte ens assembler vettigt för det som länge var den sista utposten där det krävdes: SIMD. Problemet med SIMD är att man trodde / hoppas att även det skulle gå att knäcka med "smarta kompilatorer", men efter många mer eller mindre fruktlösa försök har man kommit till insikt att de traditionella programspråken (C, C++, Java, C# etc) inte har den fundamentala design som krävs.
Nvidia knäckte den nöten först med CUDA och GPUer, andra har nu följt efter med liknande tekniker för CPU. Exempel är Intels ISPC kompilator (likt CUDA är det i praktiken ett språk som påminner om C, men med semantik som fungerar för SIMD) och Khronos SyCL (utökning av C++ samt tillhörande hjälpbibliotek, fungerar på allt från CPU, GPU till FPGA).
Allt detta gör assembler till rätt meningslöst utanför extremt specifika fall. Är nära nog hopplöst för en människa att för hand skapa bättre resultat än CUDA, ISPC och SyCL kan göra på en fraktion av tiden.
Till och med det flera av oss drog lite på smilbanden på 90-talet har ju hänt (det lät lite för bra för att kännas realistiskt), även om det fortfarande är mer undantag än regel: JIT-kompilerad kod (från t.e.x Java) kan idag ibland bli snabbare än motsvarande skrivet i C eller C++ och kompilerat direkt till maskinkod. Detta då de mest avancerade runtimes idag "lär sig" hur koden körs och JIT:ar om den under körning för att få en mer optimal maskinkod för den specifika data man råkar använda!
Ändå kul att kunna kika på DOS, det ger rejält med perspektiv på vilken enorm utveckling det varit sedan den tiden!
