Extra material för den intresserade. Inget av detta ingår som examinerande delar i kursen. Min förhoppning är att den intresserade studenten kan få mer bakgrundsinformation och en bredare kunskapsbas och förankring i datorteknik, assembler och programmering. ==================== "kio" har en websajt om gamla datorer. Bland dessa återfinns Sinclairs Z80-processorbaserade ZX80, ZX81 med flera (https://k1.spdns.de/Vintage/Sinclair/). ZX80 var en av de första "hemdatorerna" (ja jag skriver inom citationstecken för det var inget för gemene medborgare). Alla dessa datorer, liksom Vic/Commodore-datorerna osv, hade ett inbyggt program skrivet i assembler och placerat i ett ROM, Read-Only Memory. PROM-programmet kan inte raderas utan programmeras på fabrik en gång för alla. På ZX80 var minnet på 4K vilket gör att programmet - i princip - är överblickningsbart. Det finns i pdf i filen "Assembly Listing of the Operating System of the Sinclair ZX80.pdf". Läs den för att få en känsla för uppläg, utseende och komplexitet hos ett assemblerprogram. På nätet hittar du säkert databladet på Z80-processorn. Assemblerinstruktionerna heter något som du nog känner igen (typ). ==================== Nuförtiden skrivs program för dylika små datorer gärna i C som sedan kompileras till assembler. Det är alltid assembler som körs till slut. AtmelStudio kan också användas för C-programmering men det är inget vi gör i labbarna i denna kurs. Det hindrar dig dock inte från den intressanta övningen att skriva ett program i C, kompilera det och sedan se vad kompilatorn genererade för assemblerkod. Gör det och identifiera vilka assemblerrader som uppstår ur C-koden. Notera att det finns "compiler options" för optimering, där -O, -O2 och -O3 är allt mer aggressiv optimering. Koden blir successivt svårare att följa. ==================== Medan vi är inne i nördavdelningen kanske det kan vara intressant att läsa hur någon fixar assemblerbuggar i ett 30 år gammalt Atari-spel: http://www.neocomputer.org/projects/et/ ==================== http://megabeets.net är en websida där användaren beskriver reverse engineering och hackning av Gameboy bland annat. ==================== Det finns stora fördelar att tänka efter före. Detta gäller även i programmering och metoden med JSP hjälper till med detta. I samband med att man började skriva större och större program märktes det att det var viktigt att hålla pli på sig. Under slutet av 1960-talet började man på allvar studera hur program egentligen borde se ut. Det var inte tillräckligt med att de fungerade, de måste också fungera pålitligt. Visst vore det bra om man /matematiskt/ kunde bevisa att ett program var korrekt osv. Det kan vara av intresse att läsa hur man tänkte på den tiden. Mycket stoff återfinns fortfarande i dagens programmeringsspråk. Embryot till objektorienterad programmering härstammar från denna tid, så allt gammalt är inte förkastligt. Tänk på det ungdomar! Det var en stor strid, eller vad man ska kalla det, om och isåfall hur man skulle använda hopp. På den tiden kallades hopp för "GO TO" (som senare populariserades i programspråket Basic med flera. goto finns kvar i C även om den inte används så mycket. Vi kan inte undvika hopp (i formen av jmp eller branch) men får använda dem med omsorg. I assembler kan vi tillåta hopp /inom/ subrutiner men inte mellan dem. Edsger Dijkstras ursprungsartikel från 1968 (som orsakade en storm i programmerarkretsar) finns som pdf under namnet Dijkstra68.pdf Donald Knuths funderingar i samma ämne finns som Knuth74.pdf En mycket längre text som öppet beskriver Dijkstras tankegångar är Dijkstra72.pdf Den kan vara intressant för att man märker hur han har tänkt och att det är mycket resonemang som ligger bakom. ==================== Ken Shiriff har en intressant blog. I denna artikel http://files.righto.com/calculator/sinclair_scientific_simulator.html beskriver han hur han reverse engineerat en miniräknare där man på nästan inga programrader alls fått mycket funktionalitet. Numeriska algoritmer har optimerats för plats och inte för tid.