Waarom het leren van Assembler nog steeds een goed idee is.

Opmerking:
Het artikel hieronder is oorspronkelijk geschreven met Intel-type processoren in gedachte, en refereerde aan de daarbij behorende assembler-taal. Maar aangezien de argumenten die de auteur hanteert ook voor mainframes opgeld doen, vinden wij het relevant genoeg om dit artikel ook op de hlasm.com site te publiceren.

Opmerking:
Bixoft heeft "Why Learning Assembly Language Is Still a Good Idea" met toestemming van de auteur omgezet in een web-document voor her-publicatie. Daarenboven hebben wij enige kleine wijzigingen aangebracht. Desalniettemin zijn de auteursrechten van de heer Hyde onverkort van toepassing op dit document.

Contact:
Dhr. Hyde ontvangt graag uw commentaar, opmerkingen, etc. e-mail Randall Hyde. Wel graag in het engels.
Als u liever reageert in het nederlands, e-mail Bixoft.

Dit document bevat de volgende hoofdstukken:

Uitmuntende code gaat voorbij het gebruikelijke
Efficiëntie is de sleutel
Oefen je vaardigheden
Leer Assembler
Assembly is niet dood
Beheers de Low-Level Statements
Conclusie

Uitmuntende code gaat voorbij het gebruikelijke

De wereld is vervuld van rapporten over rampen op het gebied van software engineering. Bijna elke programmeur heeft wel eens moeten werken aan een project met "niet zo geweldige" broncode die moeilijk te lezen en te onderhouden was. In zeldzame gevallen krijgen sommige programmeurs de gelegenheid te werken aan een goed ontworpen systeem, een produkt van puur vakmanschap dat ontzag inboezemt en niet zelden aanleiding geeft tot de uitroep: "Dit is waarlijk uitmuntende code!"

Het is duidelijk dat professionele software engineers in al hun code dit niveau van uitmuntendheid zouden moeten nastreven. De ware vraag is echter: "Wat maakt code uitmuntend"? Eenvoudigweg "voldoen aan de specificaties" is niet voldoende om uitmuntende code te schrijven. Toegegeven, in de huidige software-industrie zou je kunnen menen dat eenvoudigweg voldoen aan de specificaties al heel bijzonder is voor een applicatie, omdat veel projecten er niet in slagen te voldoen aan de basis-doelstellingen uit het ontwerp.

Op andere gebieden echter, wordt uitmuntendheid zelden gedefinieerd als er in slagen om te doen wat er verwacht wordt; uitmuntendheid wordt juist gedefinieerd als het voorbijstreven van de verwachtingen en er boven uit stijgen. Software engineers dienen niets minder te verwachten van uitmuntende code - deze dient de standaard conventies voor de ontwikkeling van software verre te overstijgen.

Efficiëntie is de sleutel

Omdat uitmuntendheid vele aspecten kent, kan een kort artikel als dit nog niet beginnen om alle mogelijke componenten van een uitmuntend stuk software te beschrijven. In plaats daarvan zal dit artikel zich concentreren op één component van het schrijven van uitmuntende software dat de afgelopen jaren verwaarloosd is doordat computers steeds verder groeiden in kracht en capaciteit: efficiëntie.

Een ieder die al tien jaar of meer met computers te maken heeft is zich ten zeerste bewust van het fenomeen dat de machines exponentieel krachtiger worden per Euro, terwijl de gebruikers deze verbetering niet waarnemen in het gedrag van de applicaties die zij aanschaffen. Tekstverwerkers bijvoorbeeld, zijn vandaag-de-dag weliswaar duidelijk sneller dan 21 jaar geleden, maar niet 16.384 keer, zoals de Wet van Moore [1] zou doen verwachten. Onderdeel van het probleem is natuurlijk dat een deel van de toegenomen verwerkingskracht gebruikt wordt om nieuwe voorzieningen te ondersteunen (zoals bitmapped schermen). Maar de belangrijkste reden waarom software gebruikers geen snelheidstoename waarnemen, is dat veel programmeurs niet meer de tijd nemen om efficiënte software te schrijven, of ze weten domweg niet hoe zij snelle software moeten schrijven.

Onhaalbare opleverdata voor te ontwikkelen software, waardoor programmeurs niet genoeg tijd hebben om efficiënte code te ontwikkelen, zijn zeker een deel van het probleem, maar vele van de huidige programmeurs zijn opgegroeid met snelle processoren, wier snelheid veel goed maakte van allerlei slechte codeer-technieken. Zodoende hebben veel van deze programmeurs nooit hoeven leren hoe zij snelle code kunnen ontwikkelen.

Helaas weten deze programmeurs in het algemeen niet hoe zij problemen met hun software moeten oplossen, wanneer de prestaties van de software niet optimaal zijn. Vaak kramen zij dan dingen uit als "De 90-10 regel", of "Ik zal even een profiler gebruiken om de prestatie-problemen te corrigeren", maar in feite weten ze niet echt hoe ze de prestaties van hun onderpresterende applicaties moeten verbeteren. Het is allemaal leuk en aardig om te zeggen "ik ga op zoek naar een beter algoritme! ", maar dat algoritme - als er al een bestaat - te vinden en te implementeren is een totaal andere zaak.

Meestal kun je een hele goede prestatie-verbetering bereiken door eenvoudigweg de implementatie van een bestaand algoritme te verbeteren. Een wetenschapper kan dan wel beargumenteren dat een " constante" verbetering minder goed is dan bijvoorbeeld een overstap van een algoritme met O(n^2) prestaties naar een met O(n log(n) ) prestaties, maar in de praktijk kan een verbetering met een constante factor twee of drie, doorgevoerd voor een compleet stuk software, het verschil maken tussen een bruikbare applicatie en een die gewoon te traag is om er plezierig mee te kunnen werken. En het is nou net dit soort optimalisatie waarmee de meeste moderne programmeurs zo bitter weinig ervaring hebben.

Jammer genoeg is het schrijven van efficiënte software een vaardigheid; een die geoefend moet worden om haar te leren en die geoefend moet worden om haar te onderhouden. Programmeurs die deze vaardigheid nooit oefenen zullen haar onmogelijk kunnen inzetten op de dag dat zij ontdekken dat hun applicatie te traag is. Zelfs wanneer een programmeur de vaardigheid eenmaal heeft opgebouwd om efficiënte software te schrijven, dan nog moet die programmeur deze vaardigheid regelmatig oefenen om die vaardigheid te behouden. Zodoende zijn er twee redenen waarom programmeurs vandaag de dag geen efficiënte (en uitmuntende) code schrijven: ze hebben allereerst nooit geleerd hoe ze efficiënte code kunnen schrijven, of zij hebben hun vaardigheid op dit punt laten atrofiëren tot op het punt waarop zij als vanzelfsprekend geen efficiënte code meer schrijven.

Oefen je vaardigheden

Voor programmeurs die hun vaardigheden hebben laten verwateren door gebrek aan oefening is de oplossing overduidelijk: oefen je in het schrijven van efficiënte code, zelfs als dat voor het project niet per se nodig is. Dit betekent natuurlijk niet dat een oefenende programmeur belangrijke zaken als opleverdata, leesbare en onderhoudbare code, etc. zou moeten opofferen aan de efficiëntie van zijn code.

Wat het wel betekent, is dat de programmeur de efficiëntie in het oog moet houden als hij/zij de software aan het ontwerpen en implementeren is. De programmeur dient een bewuste beslissing te nemen wanneer hij/zij een minder efficiënte implementatie verkiest boven een meer efficiënte. Deze keuze dient gebaseerd te zijn op economische of technische overwegingen, in plaats van het eerste het beste wat opkomt maar te implementeren. In veel gevallen is deze simpele afweging van verschillende (en mogelijk meer efficiënte) implementaties alles wat nodig is om uitmuntende code te produceren. Uiteindelijk is het schrijven van de efficiëntere implementatie vaak niet eens moeilijker dan het schrijven van de minder efficiëntere. Alles wat een ervaren programmeur nodig heeft zijn een aantal alternatieven om uit te kiezen.

Helaas hebben onrealistische planningen voor software ontwikkeling vele professionele ontwikkelaars ertoe verleid om de zorgvuldige afwegingen in de ontwikkeling en implementatie van de software over te slaan. Het gevolg is, dat vele professionele programmeurs de gewoonte om uitmuntende code te schrijven hebben opgegeven. Gelukkig is dit proces eenvoudig om te keren door zo vaak als mogelijk goede methodologieën voor software ontwikkeling te hanteren, zoals het overwegen van verschillende algoritmen en hun alternatieve implementaties.

Leer Assembler

Maar hoe zit het dan met de programmeurs die überhaupt nooit geleerd hebben om efficiënte code te schrijven? Hoe leert men hoe men een applicatie efficiënt implementeert? Helaas verbreiden universiteiten en hogescholen tegenwoordig in hoofdzaak het idee dat je je over de implementatie van een algoritme niet druk hoeft te maken, zolang je maar een goed algoritme kiest. Veel te veel studenten beëindigen hun studie inzake data structuren en algoritmen met de houding dat het bereiken van een constante prestatie-verbetering (dat wil zeggen: O(1)) eigenlijk de moeite niet loont, en dat dit soort pogingen tot verbetering verspilling van tijd zijn.

De voortdurende vooruitgang in computer architectuur heeft dit probleem alleen maar verergerd. Je zou bijvoorbeeld een programmeur kunnen horen zeggen: "Als dit programma een beetje sneller moet lopen, wacht dan maar een jaartje, dan zijn de processoren twee keer zo snel; er is dus geen reden om je zorgen te maken." Het is deze houding, wellicht nog meer dan enige andere reden, die maakt dat de prestaties van software geen gelijke tred houden met de prestaties van processoren.

In het volste vertrouwen dat toekomstige verbeteringen in de prestaties van processoren hun problemen zullen oplossen, schrijven zulke programmeurs steeds weer nieuwe applicaties die langzamer zijn dan nodig, ongeacht welke processor zij op dat moment gebruiken. Natuurlijk heeft de programmeur, tegen de tijd dat de processoren snel genoeg geworden zijn om deze programmatuur te kunnen draaien, alweer allerlei " verbeteringen" aangebracht in de software, die daardoor opnieuw afhankelijk is geworden van nog meer toekomstige verbeteringen in processor-prestaties. De cyclus herhaalt zich vrijwel eindeloos, doordat de processor-prestaties de toenemende capaciteitsvraag van de applicaties niet kunnen bijbenen, totdat uiteindelijk de levenscyclus van de software ten einde loopt en de programmeur de cyclus opnieuw opstart met een andere applicatie.

Feitelijk is het echter goed mogelijk om software te schrijven die efficiënt draait op huidige processoren. Jaren terug deden programmeurs al geweldige dingen met software die draaide op acht-bit 5MHz 8088 processoren (of nog langer geleden op sub-megahertz mainframe processoren). De technieken die zij toen gebruikten om de allerhoogste prestaties uit hun eenvoudige processoren te persen vormen vandaag ook de sleutel tot goed presterende applicaties. En hoe verkregen zij dan wel een redelijke prestatie uit zulke eenvoudige processoren? Het antwoord is geen geheim: zij begrepen hoe de onderliggende hardware werkte, en zij schreven hun software dienovereenkomstig. Diezelfde kennis van de onderliggende hardware is ook vandaag nog de sleutel tot het schrijven van efficiënte software.

Van oudere programmeurs kun je vaak het commentaar horen dat waarlijk efficiënte software geschreven wordt in assembler. Echter, de reden dat zulke software efficiënt is, zit hem niet in het feit dat de taal van implementatie op magische wijze de software efficiënt maakt - het is heel goed mogelijk om inefficiënte software te schrijven in assembler. Neen, de werkelijke reden waarom assembler programma's meer efficiënt plegen te zijn is gelegen in de omstandigheid, dat de taal de programmeurs dwingt om bij elke instructie die zij schrijven na te gaan hoe de onderliggende hardware er mee om gaat. En dat is precies waar het om gaat als je wilt leren hoe je efficiënte code kunt schrijven: de sterke en zwakke punten van de machine in de gaten houden.

Diezelfde oudere programmeurs die claimen dat waarlijk efficië nte code geschreven is in assembler, hebben nog een waardevol advies: als je wilt leren hoe je uitmuntende code kunt schrijven in een hogere taal, leer dan eerst te programmeren in assembler.

Dit is een heel goed advies. Per slot van rekening vertalen compilers hun broncode van "hoog niveau" in "laag niveau" machine instructies. En als je de assembler-taal voor jouw specifieke machine kent, dan ben je dus ook in staat om de constructies in je hogere taal te relateren aan de instructies in machine-taal die de compiler genereert. En dan zul je beter in staat zijn om een keuze te maken uit de beschikbare constructies in je hogere taal, gebaseerd op je begrip van de wijze waarop compilers de hun aangeboden broncode vertalen in machine code.

Maar al te vaak kiezen programmeurs in een hogere taal bepaalde constructies in hun taal zonder te weten wat het kost om de betreffende statements uit te voeren. Bij het leren van assembler leert programmeur automatisch ook de kosten in te schatten van diverse constructies in hogere talen. Zelfs als de programmeur nimmer werkelijk applicaties schrijft in assembler, dan nog wordt de programmeur zich door deze kennis bewust van de problemen met bepaalde inefficiënte constructies in hogere talen, waardoor hij/zij deze kan vermijden in zijn/haar code.

Het leren van assembler vereist, net als het leren van elke andere programmeertaal, een behoorlijke inspanning. Het probleem hierbij is, dat de assembler-taal op zich verraderlijk eenvoudig is. De 20 tot 30 machine instructies die je in een gewone assembler applicatie tegenkomt, kunt je in een paar dagen leren. Je kunt in een paar weken zelfs wel leren hoe je die instructies kunt gebruiken om problemen op te lossen op dezelfde manier als je die op zou lossen in een hogere taal.

Helaas is dit niet het soort kennis dat een hogere-taal programmeur nuttig vindt wanneer het er op aan komt om efficiënte code te schrijven in een hogere taal. Om voordeel te halen uit assembler-kennis dient een programmeur leren om in assembler te denken. Dan kan zo'n programmeur zeer efficiënte code schrijven in een hogere taal door in assembler te denken en in die hogere taal te schrijven. Hoewel op deze wijze geschreven programmatuur waarlijk uitzonderlijk is, kleeft er een klein probleempje aan deze benadering: het vergt een behoorlijke inspanning om dit niveau te bereiken. En dat is een van de redenen waarom dergelijke code uitzonderlijk is: omdat zo weinig beoefenaren in staat zijn om haar te produceren.

Assembly is niet dood

In de loop van de jaren 90 van de vorige eeuw heeft assembler een slechte reputatie ontwikkeld. Vooruitgang in compiler technologie, verbeterde CPU prestaties, alsmede de "software crisis" droegen alle bij aan de beeldvorming dat assembler een "dode taal" was geworden, die nergens meer toe diende. Doordat assembler iets lastiger te leren is dan de traditionele hogere programmeertalen omarmden studenten (en leerkrachten!) maar al te graag dit nieuwe paradigma, waarbij zij de moeilijk te leren assembler-taal lieten voor wat het was ten faveure van steeds hogere en hogere talen.

Het enige probleem met de neergang van de assembler-taal is, dat met het verminderen van haar populariteit ook het percentage programmeurs afnam dat begreep welke gevolgen de code die zij schreven had op de lagere niveaus. De programmeurs die verkondigden dat assembler dood was, waren al in staat om in assembler te denken, en wisten hoe zij hun begrip voor de onderliggende zaken konden toepassen in hun hogere code. Zo genoten zij voordeel uit hun assembler-kennis bij het schrijven van hun code in hogere talen. Maar naarmate er meer nieuwe programmeurs kwamen die niet het voordeel hadden om ooit enkele applicaties in assembler te hebben geschreven, begon de efficiëntie van software toepassingen af te nemen.

Hoewel het onzinnig zou zijn om te stellen dat programmeurs weer commerciële toepassingen zouden moeten schrijven in assembler, is het inmiddels wel duidelijk dat het in onbruik raken van de assembler-taal grote gevolgen heeft gehad voor de efficiëntie van moderne software. Om deze trend te keren dienen programmeurs ofwel opnieuw beginnen met het aanleren van de assembler-taal, of zij moeten de benodigde kennis van onderliggende zaken op een andere manier verwerven.

Het leren van assembler is nog steeds de beste manier om de fundamentele organisatie, de architectuur, van de onderliggende machine te leren kennen. De programmeurs die de moeite nemen om de assembler-taal te leren beheersen worden vaak de toppers van de programmeurs die met hogere talen werken. Hun vermogen om de juiste constructies te kiezen in de hogere taal teneinde efficiënte code te produceren, hun vermogen om gedisassembleerde hogere code te lezen en om geniepige bugs te ontdekken, alsmede hun begrip van de werking van het gehele systeem verheft hen tot welhaast legendarische status onder hun gelijken. Dit zijn de programmeurs waar eenieder naar toe gaat wanneer zij zich afvragen hoe iets te implementeren. Dit zijn de vakmensen ieders respect afdwingen. Dit zijn degenen die door anderen worden nagevolgd. Dit zijn de programmeurs die waarlijk uitmuntende code schrijven.

Als kennis van assembler programmeurs helpt om uitzonderlijk te worden, dan rijst een voor de hand liggende vraag: "Waarom leren niet meer programmeurs de assembler-taal?" Een deel van het probleem bestaat uit vooroordelen: veel leerkrachten aan hogescholen en universiteiten beginnen bij het geven van een assembler-cursus met een opmerking in de trant van "Niemand hoeft dit echt te weten, en je zult het nooit gebruiken, maar het staat op het programma, en dus moeten we ons er maar doorheen zien te worstelen." Na vier jaar geconfronteerd te zijn met een dergelijke benadering door hun leerkrachten, is het niet verwonderlijk dat de studenten vervolgens werkelijk helemaal niets meer met programmeren in assembler te maken willen hebben.

En toch kun je je afvragen waarom niet meer programmeurs deze waardevolle kennis oppikken als het hun eenmaal duidelijk wordt dat de waarlijk uitmuntende programmeurs diegenen zijn, die de assembler-taal beheersen. Het voornaamste probleem is dat - traditioneel gezien - de meeste programmeurs het moeilijk vinden om assembler te leren. Assembler is radicaal anders dan de meeste hoger talen; daardoor is het leren van assembler bijna net zo veel werk als voor de eerste keer leren programmeren.

Voor iemand die assembler wil leren, lijkt het vaak alsof geen van de reeds eerder opgedane kennis en ervaring nog bruikbaar is. Maar al te vaak raakt een programmeur die assembler wil leren gefrustreerd over het feit dat hij/zij een bepaald doel moet bereiken in een hogere taal, maar er niet in slaagt te bedenken hoe datzelfde doel in assembler bereikt kan worden. Voor veel programmeurs blijkt het uiteindelijk een onoverkomelijk probleem om de omschakeling te maken van "denken in een hogere taal" naar "denken in assembler".

Al meer dan tien jaar ben ik als docent assembler verbonden aan de Universiteit van Californië, en ik ben mij al die tijd bewust geweest van de problemen die studenten hebben om de overgang te maken van de hun bekende manier van programmeren in een hogere taal naar de werkwijze die verband houdt met programmeren op een lager niveau.

In de vroege 1990-er jaren kwam Microsoft met een oplossing in de vorm van Microsoft Macro Assembler (MASM) v6.0 - waarin ondersteuning was opgenomen voor structuur-elementen uit hogere talen in de assembler-omgeving. Hoewel deze nieuwe statements beslist niet tot de echte assembler behoren, verschaffen zij wel een vereenvoudigd overgangspad van traditionele, opdracht-georiënteerde, hogere programmeertalen naar assembler. Programmeurs kunnen bekende statements als IF, WHILE, en FOR gewoon blijven gebruiken terwijl zij andere aspecten van assembler programma's aan het leren zijn. Hierdoor kan de programmeur bij her leren programmeren in assembler kleinere stappen maken, en hoeft niet ineens in het diepe te springen.

Ook voor IBM's High-Level Assembler (HLASM) zijn al heel lang verschillende macro bibliotheken beschikbaar, waarin dezelfde functionaliteit wordt geïmplementeerd.

Beheers de Low-Level Statements

Vanzelfsprekend kunnen programmeurs zichzelf geen assembler programmeur noemen totdat zij de overeenkomstige low-level statements beheersen. Desalniettemin vormen deze structuur-elementen uit hogere talen een prima brug tussen de hogere talen en de assembler-taal, waardoor de studenten hun kennis van programmeren in hogere talen kunnen hergebruiken bij het leren van assembler. Helaas zijn er weinig tot geen studieboeken die het programmeren in assembler leren met behulp van deze benadering waarbij de hogere structuur-elementen die in MASM (en HLASM) tegenwoordig beschikbaar zijn.

Een ander probleem met de overgang van hogere talen naar de lagere niveaus is dat veel hogere talen grote bibliotheken leveren, met routines die allerlei taken kunnen uitvoeren, zoals input, output, conversies van getallen, en tekst-bewerkingen. Een groot probleem waar beginnende assembler-programmeurs mee geconfronteerd worden, is dat zij bij voorbeeld numerieke gegevens moeten kunnen in- of uitvoeren, dan wel dat zij numerieke gegevens moeten omzetten in tekstuele weergave (of andersom) om zelfs maar de meest eenvoudige programma's te kunnen schrijven en testen. Ongelukkigerwijze laten de meeste assembler ontwikkel-omgevingen het over aan de programmeur om deze basis-functionaliteit voor hun applicaties op te bouwen. Dit stelt ons voor een kip-ei probleem: het is moeilijk om assembler te leren zonder deze functies, maar je kunt zulke functies pas schrijven als je assembler geleerd hebt.

Opmerking:
HLASM beschikt standaard over een groot aantal macro's voor het plegen van I/O. Voor het converteren van getallen worden verscheidene instructies ondersteund. Dit verschaft HLASM-studenten een voordeel ten opzichte van MASM-studenten.

Alleen de meest vastberaden programmeurs slagen er in deze obstakels effectief te overwinnen en de assembler-taal te leren. Hierdoor is het gebruik van assembler gedurende de 1990-er jaren en de vroege jaren van de huidige eeuw blijven afnemen. Omdat ik zag hoe de vermindering van de efficiëntie en kwaliteit van software volgde op het afnemend gebruik van assembler, begon halverwege de jaren 90 aan een kruistocht om programmeurs aan te moedigen om te leren programmeren in assembler.

De eerste mijlpaal die ik bereikte was het uitbrengen, halverwege de jaren 90, van de elektronische editie van "The Art of Assembly Language". Dit boek, tezamen met de bijbehorende "UCR Standard Library for 80x86 Language Programmers" verminderde de moeite die het kostte om assembler te leren. Tienduizenden programmeurs hebben de assembler-taal geleerd aan de hand van dit boek en de bijbehorende bibliotheek met routines.

Het enige probleem met de elektronische editie van "The Art of Assembly Language" en de "UCR Standard Library for 80x86 Language Programmers" was dat zij bij hun verschijning op het internet al bijna verouderd waren, omdat zij de lezer leerden om 16-bit DOS applicaties te schrijven. De uitgave viel bijna samen met het uitbrengen van windows 95, wat een van de laatste nagels was in de doodkist voor het 16-bits programmeren.

Nog steeds op kruistocht begon ik te werken aan een volkomen nieuwe assembler met hogere structuur-elementen (HLA, de High-Level Assembler), een nieuwe versie van "The Art of Assembly Language", en een nieuwe 32-bits, HLA-gebaseerde verzameling routines. Deze inspanningen resulteerden in de uitgave van de geschreven editie "The Art of Assembly" (AoA) in 2003. Tot nu toe hebben duizenden en duizenden programmeurs deze nieuwe manier van assembler leren omarmd, gebruik makend van AoA, HLA, en de HLA Standaard Bibliotheek.

Hoewel "The Art of Assembly Language" en HLA dagelijks de rijen der assembler-programmeurs aanvullen, is de oplossing die zij bieden er een voor de volgende generatie programmeurs.

Maar hoe moet dat dan met programmeurs die de gelegenheid gemist hebben om tijdens hun opleiding assembler te leren en zich de concepten van machine-organisatie eigen te maken - voordat de harde realiteit van project-planningen hen berooft van de tijd die nodig is om de vereiste ervaring op te doen voor het schrijven van uitmuntende code? De vraag is "kun je effectief machine-organisatie leren aan professionele programmeurs zonder tegelijkertijd de assembler-taal te onderwijzen?"

Hoewel het redelijk duidelijk is dat assembler leren het beste advies is dat ik kan geven aan eenieder die geïnteresseerd is in het schrijven van uitmuntende en efficiënte code, ben ik er tevens van overtuigd dat men studie kan maken van machine-organisatie zonder assembler te leren, en daarbij toch te leren om betere code te schrijven. Wellicht zal dergelijke code minder goed zijn dan die van de programmeurs die zich wel assembler-kennis hebben eigen gemaakt, maar het zal beter zijn dan de software die zij geschreven zouden hebben zonder die kennis.

Hoewel het moeilijk is om het idee van assembler leren te verkopen aan de huidige generatie programmeurs (twintig jaar anti-assembler propaganda heeft daar wel voor gezorgd), is het heel belangrijk dat de meeste programmeurs zich realiseren dat zij betere code zouden kunnen schrijven als zij maar "een beetje meer kennis hadden van de werking van de onderliggende hardware". Wat dus nodig is, is lesmateriaal om gegevens-weergave, geheugen-organisatie, elementen van computer architectuur, input/output te onderwijzen in samenhang met de statements in de hogere programmeertalen.

Dat wil zeggen: leer ze alle dingen die ze ook zouden opsteken als zij zouden leren programmeren in assembler, maar dan met uitzondering van het leren werken met de concepten van de assembler-taal. Recentelijk ben ik begonnen om specifiek voor deze groep boeken te schrijven zoals "Write Great Code, Volume One: Understanding the Machine"; een boek over machine-organisatie die niet specifiek ingaat op het programmeren in assembler. Hoewel iemand die studie maakt van machine-organisatie wellicht niet zulke geweldige code zal schrijven als iemand die de tijd neemt om zich het programmeren in assembler eigen te maken, is het mijn hoop dat diegenen die nooit zouden overwegen om assembler te leren, wel bereid zullen zijn om een boek als "Write Great Code, Volume One: Understanding the Machine" op te pakken en zo toch te leren om betere code te schrijven, zelfs als dat geen waarlijk uitmuntende code zal zijn.

Conclusie

Om uitmuntende code te schrijven moet je efficiënte code schrijven. Om efficiënte code te schrijven moet een goed algoritme kiezen en moet je dat algoritme goed implementeren. De beste implementaties zullen geschreven worden door hen die de assembler-taal beheersen of die de consequenties voor de lagere niveaus overzien voor de keuzes die zij maken in hun hogere programmeertaal. Dit betekent niet dat we terug zullen keren naar de dagen waarin grote commerciële applicaties volledig in assembler werden geschreven. Maar om de trend van software steeds langzamer lopende software op steeds snellere processoren tegen te gaan, zullen programmeurs moeten gaan overwegen welke gevolgen de code die zij schrijven zal hebben op de onderliggende niveaus.

Dus is het leren van de assembler-taal, en het denken in assembler, een van de beste dingen die je kunt doen als je betere code wilt gaan schrijven; zelfs je niet van plan bent om ooit nog een regel assembler-code te gaan schrijven.

Opmerking 1:
De wet van Moore stelt dat de semiconductor technologie de capaciteit of prestaties per prijs-eenheid elke 18 maanden verdubbelt.
De wet van Moore zegt niets over prestaties. Zij stelt slechts dat het aantal transistors elke twee jaar verdubbelt. Een gevolg van de vooruitgang inzake de wet van Moore is, dat tot op heden de prestaties gelijke tred hebben kunnen houden.

Over de auteur:
Randall Hyde is de auteur van de recentelijk verschenen boeken "Write Great Code" en "The Art of Assembly Language" (beide van "No Starch Press"). Beide hogelijk aanbevolen bronnen van informatie over assembler voor Intel-type processoren. Voor HLASM en mainframe processoren bestaan vergelijkbare bronnen.

Deze site is aangesloten bij WebRing. Bekijkt u gerust de lijst van mainframe-gerelateerde sites.		Dino's zijn niet dood. Ze zijn gezond en wel en leven in computer-centra overal om ons heen. Zij spreken in tongen en doen wonderbare magie met computers. Pas op voor de dino! En voor het geval u zit te wachten op het definitieve einde van deze dino's: onthoud dat dino's de wereld 155 miljoen jaren hebben geregeerd!
Dino's en andere anachronismen [ Aanmelden \| Ring Overzicht \| Willekeurig \| << Vorige \| Volgende >> ]

Naar Uitmuntende code gaat voorbij het gebruikelijke.
Naar Efficiëntie is de sleutel.
Naar Oefen je vaardigheden.
Naar Leer Assembler.
Naar Assembly is niet dood.
Naar Beheers de Low-Level Statements.
Naar Conclusie.

Hieronder vindt u het logo van onze sponsor en logos van web-standaarden waaraan deze web-pagina voldoet.