Det er vanlig blant doktorgradsstudenter i Storbritannia å snakke om noe som kalles «second year blues». Jeg tror det er en slags blanding av mange følelser, delvis at forskningen ikke fullt så spennende som man hadde trodd, kanskje man er usikker på om man kommer til å få en jobb, pluss at man begynner å føle presset for å bli ferdig. Jeg tror ikke dette er så vanlig i Norge, og jeg gjetter på at det skyldes at vi gjennomsnittlig er litt eldre når vi begynner på doktorgrad, pluss at doktorgraden faktisk er en jobb med normal lønn. Jeg husker i allefall mitt andre år som en lykkelig tid uten bekymringer.

Jeg begynner imidlertid å føle en slags «final year blues» nå. Jeg regner jo med at jeg blir ferdig sånn omtrent på tiden, og jeg regner også med at jeg greier å skaffe meg en jobb, men jeg begynner å føle en slags snikende frykt for at jeg snart er ferdig med å lære nye ting. Det er åpenbart ikke sant, i allefall ikke hvis jeg får en spennende jobb, men det er likevel en del ting man ikke lærer seg mens man jobber. For eksempel assembly.

For de som ikke vet hva assembly er tenkte jeg å ta en kjapp gjennomgang av programmeringens historie, slik jeg ser for meg at det godt kan ha vært. Til å begynne med hadde man datamaskiner der komponentene ble skrudd sammen for å utføre én bestemt oppgave. Ville man programmere den om måtte man bygge om maskinen. Så kom etterhvert maskiner der man kunne endre oppførselen ved å bytte om på ledninger, som en gammeldags telefonsentral, og etterhvert maskiner som kunne programmeres mer som vi mener det i dag, ved at man ikke trengte å koble om ting, men kunne legge ulike programmer i minne. Skjønt dette skjedde fortsatt i maskinkode, skrevet med binære tall, så det var en aktivitet for spesielt interesserte.

Og her kommer vi til assembly. Assembly, også kalt assembly language, ligger et lite hakk over maskinkode, ved at man innførte kommandoer for de mest grunnleggende operasjonen, slik som «putt tallet 16 på minneadresse 43» og «legg sammen 12 og tallet som ligger i minneadresse 01, og skriv resultatet til minneadresse 01». Når man så hadde skrevet assembly kunne man bruke noe som kalles en assembler for å oversette dette til maskinkode, som maskinen kan kjøre.

Sener fikk man nyskapende ting som FORTRAN, som kom i 1957, og lot deg for eksempel legge sammen to tall uten å måtte ha direkte kontroll på minneadresser. På et eller annet tidspunkt dukket også hullkortene opp, uten at jeg er skråsikker på hvordan de passer inn i det store bildet, men de forsvant heldigvis igjen. Videre fikk man språk som lisp (1958), COBOL (1959), C (1973), C++ (1983), Perl (1987), Haskell (1990), Java (1991), Python (1991), Lua (1993) og JavaScript (1995), og det har nok vært en generell trend at man har beveget seg lengre og lengre bort fra hvordan maskinen faktisk fungerer. I løpet av denne utviklingen har man ofret noe ytelse, men til gjengjeld har man fått språk som gjør det praktisk mulig med store kodeprosjekter skrevet av hundrevis av mennesker.

For min egen del er jeg imidlertid mer opptatt av ytelse enn brukervennlighet, og kanskje mest av alt opptatt av kombinasjonen teoretisk ytelse og skikkelig dårlig brukervennlighet, jamnfør min besettelse med fluefiske. Og derfor har jeg altså lyst til å lære meg assembly. Pluss at det høres fryktelig barskt ut. Les bare dette utdraget av en epost jeg fikk fra mannen på support når jeg spurte om det var mulig å kjøre med 80-bits presisjon:

Hardwareregistrene til AMD hadde, sist jeg så etter, 16 ekstra-bit (80 vs. double=64) nettopp for å hjelpe med presisjonstap i mellomresultater, men hvis du vil skrive et program som stoler på å bruke dem, må du nesten
a) vippe frem assembleren
b) utføre en tarmskylling på fortrankompilatoren for å finne hvilken av 3 konkurrerende non-standarder for funksjonskall den har størst tro på
c) blåse en lang marsj i å kjøre koden uforandret på nye/andre maskiner.

Seriøst? Får ikke du også lyst til å lære assembly, slik at du kan finne frem assembleren når det trengs?

Jeg gjorde et lite søk etter en assembly-tutorial, for det er slikt man gjør når man egentlig burde skrive artikler og avhandling, og jeg fant opptil flere lovord om en bok som heter The Art of Assembly Language, som finnes i opptil flere papirutgaver, og dessuten som en 1400-siders pdf man lett finner med Google. Jeg begynte å lese litt i den, og en stund trodde jeg faktisk den var ganske ny, helt til jeg kom over denne biten, i seksjonen med gode argumenter for å lære assembly:

If you give someone an inch, they’ll take a mile. Nowhere in programming does this saying have more application than in program memory use. For the longest time, programmers were quite happy with 4 Kbytes. Later, machines had 32 or even 64 Kilobytes. The programs filled up memory accordingly. Today, many machines have 32 or 64 megabytes of memory installed and some applications use it all.

Jeg merker meg imidlertid at det finnes en oppdatert papirutgave fra 2010, og den vurderer jeg seriøst å kjøpe. Den virker i allefall godt skrevet, og de få sidene har jeg lest så langt har vært svært interessante.