Bra kurs i assembler med simulator för förståelse mha 6502

[swesysmgr]

Allt beror på hur man vill lära sig. I bästa världar tror jag top-down via bra litteratur är bäst. Men det är sällan några nybörjare har lust att läsa böcker pärm till pärm.

Men främsta lärdomen vid lite mer praktiskt övning är troligtvis insikten om vikten av att vara strukturerad och lägga mycket tid på förarbete. Folk som slänger sig framför tangentbordet för att programmera direkt lyckas sällan med något komplicerat.

Folk som enbart skall ronka teori och förstudier och skall skriva det perfekta programmet varje gång tenderar å andra sidan att aldrig bli klara.

Jag tycker simulatorn var fin och att det är mycket enklare och snabbare att lära sig asm på arkitektur B om man först lärt sig grunderna på arkitektur A även om A är 30 år gammal.

[SeniorLemuren]

Mina erfarenheter genom livet pekar nog på att det är Learning-by-doing som gäller. Som exemepel så lärde jag mig på gamla dar, hyfsad Spanska på 3 år när jag bodde i Dominikanska Republiken.

När jag var ung läste jag Franska på kvällskurser under ett par år och lärde mig kommunicera något lite med nöd och näppe. På skolbänken lär man sig säkert en massa teori, men att sedan använda det i verkligheten är en helt annan sak.

Jag tror inte att simulatorn är bortkastad tid om man vill lära sig assembler. Jag tillhör den gamla stammen som programmerade om ABC-80 tolken för att kunna läsa andra bandprotokoll (Ecma34), gjorde en hel del drivrutiner i assembler för att få företagets skrivare att skriva ÅÄÖ i de första PC-datorena. När jag för ett par år sedan började programmera PIC16XXX så hade jag helt klart en hel del nytta av mina gamla kunskaper i Assembler från urtiden.

[blueint]

Same shit different registernames

[4kTRB]

Sidan http://www.6502.org/homebuilt/ är riktigt bra och
innhåller massa cool projekt runt 6502. Som någon skriver i ett av
projekten så föredrar han Z80 pga dokumentation, pris och tillgänglighet.
6502 har dock något som inte Z80 har nämligen popularitet.
Dessa projekt är nog väldigt inspirerande att läsa igenom om man
tänker lära sig hur en dator fungerar.

[gkar]

Jo, assembler har sin plats.
Idag är det mest för debuggning, även om jag då och då skriver en del.
Men om det går, vilket det inte gör, så skriver man i C.
Sedan att det blir mer och mer jobbigt att skriva optimerad assemblerkod ju nyare processor man har pga pipelining, datadependancies, early/late cycle, cache hantering etc.

De flesta processorer är ganska lika någon annan.
X86, NS32000, ARM, VAX11, 68k är ungefär likadana. (Ja, ARM som är RISC är väldigt lik 68k)
Alla 8 bitars ackumelatormaskiner har samma principer.
DSPar skiljer sig genom att de är enkla och lite mer snåriga.

Same shit, kan du en, kan du lära dig alla andra utan för mycket arbete.
(Oki, instruktionstiming på TI C64DSP är lite snårigt...)

Nu är det nog dags att återgeå till arbetet eller, $4e73 om jag varit en 68k!

[4kTRB]

Jag vet inte hur de skriver kompilatorer nu för tiden?
Görs det helt och hållet i högnivåspråk?

[gkar]

Japp.
Det finns ingen anledning att ha assembler i en kompilator. Det är ju bara parsning och mappning av instruktionsuppsättningen.

Däremot är många av biblioteksanropen optimerad assemblerkod, men det är ju en annan sak...

[Nerre]

Jag har rotat lite i hur man skriver kompilatorer, mest för att jag för typ 20 år sen hade funderingar på att skriva en korskompilator för att kunna kompilera Z80-kod på min 286:a och på nåt sätt slanga över det till min gamla Spectravideo 328. Det blev aldrig nåt av de planerna men tankarna har suttit i bakhuvudet.

Det finns en intressant "kurs" som heter "Let's build build a compiler" som konstruerar en kompilator för ett pseudospråk, men den är inte så rolig för han ändrar sig lite under resans gång.
http://compilers.iecc.com/crenshaw/

Men den teknik han använder är nästan frånkörd idag.

Jag tror gcc är idag uppbyggd på ett modulärt sätt så att dess dela kan användas för att skriva kompilatorer för vilket språk som helst och som kompileras till vilken assemblerkod som helst.

Om jag nu inte minns fel så använder man först verktyg i stil med flex för att "tokenisera" källkoden (som jag förstått det innebär det i princip att källkoden omvandlas till ett "träd"). Man bryter så att säga ner källkoden i sina beståndsdelar, basera på språkets definition.

Detta träd konverteras sen till nån form av pseudokod, från den skapar man sen valfri assembler och assemblerar.

Det innebär att man använder universella verktyg hela vägen man behöver bara skriva två saker:

1. Språkdefinitionen (för den lexiska analysen och uppdelningen)
2. Hur pesudoassemblern ska konverteras till riktig assembler

Men idag börjar man lite gå ifrån detta eftersom det är svårt att optimera bra, ska kompilatorn kunna optimera måste den ju veta hur processorn är uppbyggd.

Men man skriver i vilket fall som helst själva kompilatorn i högnivåspråk, finns ingen anledning att skriva den i assembler eftersom man kan skriva kompilatorn på en annan (befintlig) plattform och korskompilera.

[Swech]

Det är en jädra skillnad på swahili och engelska
Köra assembler på olika processorer är däremot mycket lika.
Det är långt ifrån bortkastat.
Har kört
Z80
68HC11
68000, 030,060 Klar favorit men ack så långsam
486
PIC16
AVR 8 bit
Den som skiljer sig mest är PIC. Övriga är i princip samma sak

Jag kör assembler dagligen.
Men det är för att ingen annan lägger sig i och kommer med
allsköns högnivå elände där man verkligen kan skriva saker
som för processorerna är swahili.

Swech

[blueint]

Hur kommer det sig att du valt assembler? och vilken CPU?

[4kTRB]

En sak jag minns från då jag skrev assembler-rutiner
var att beräkningar med vissa tal (men enbart dessa)
gick att utföra en hel del snabbare med klurig kod.
Jag undrar om kompilatorer har koll på vad som är
möjligt att utföra smart i alla lägen?

[Swech]

blueint:
Jag kör AVR.
Sedan har jag kört assembler i över 20 år och gamla hundar har svårt....

Har man kört tillräckligt många projekt så inser man att det absolut
viktigaste är att:
Programmet måste vara lätt att läsa
Programmet måste vara robust
Programmet måste vara lätt att ändra om t.ex. hårdvara ändras
eller funktioner ändras

Det finns några saker med t.ex. C som får mig att rysa.
1. Det är alldeles för lätt att klippa och klistra
2. man vet inte riktigt vad som kommer ut från kompilatorn.
vet inte hur många trådar man sett där folk trixar med denna
eller har kompilerat samma kod med andra inställningar och
allt slutar att funka...

Swech

[Icecap]

Jag började också med assembler i sin tid, då med Z80. Jag har sedan lärt mig att den faktisk hade en trevlig struktur för programmering.

Och jag har testat en del av teknikerna från den tid för att testa skillnaden i hastighet, mest för att se hur bra man kan optimera i C men ett par gångar för att undvika att ladda in ett lib. Ta den enkla funktion att multiplicera med 10, den använder jag en del då jag gillar att överföra data via serieport och i ASCII-form (lätt att sniffa).

Då behövs en funktion av typen:
Resultat = Resultat * 10 + Nästa siffra. Och *10 sker ju oftast med den inbyggda multipliceringsfunktion i C. Men jag har testat att göra som i asm:
* Kopiera Result till en mellanvariabel.
* Dubbla Result två gg vid att shifta det två gg till vänster.
* Addera kopian. Result är då multiplicerat med 5.
* Shifta Result ett steg ytterligare till vänster vilket ger en 10-faltig multiplicering.

Allt såklart gjort i C och det finns en hastighetsskillnad! Inte enorm eller livsavgörande men den finns o i ett fall behövde den inbyggda multipliceringsfunktion inte att laddas in vilket gjorde det möjligt att programmet kunde pressas in i PIC'en.

Så även om det var kunnande från Z80-tiden - som ju är en ganska annan struktur än en PIC - samt ett annat programmeringsspråk fungerade själva tekniken utmärkt och löste ett problem.

Det är dock - i mitt tycke - svårt att göra bra material att lära ut µC-funktionalitet med, helt enkelt för att utvecklingen går så snabbt att de praktiska exempel man kan ge blir föråldrat innan man har hunnit skriva klart materialet. Det finns många tutorials om PIC på nätet - men hur mycket respekt är det om en PIC16F84 numera? Alla vet ju att den är stenålder.

Och då det är roligast att faktisk kunde lära sig IRL är det viktigt att materialet ger verklig tillgång till en verklig funktion, alltså är t.ex. 6502 kanske inte en helt lyckad strategi att utgå ifrån, helt enkelt för att det är snudd på omöjligt att skaffa ett system som baseras på den µC och att skapa ett fungerande system blir dyrt, besvärligt och nära nog omöjligt att få till att fungera utan ett intimt kännedom om µC-system - vilket man ju inte har i det fall.

Sedan har jag alltid haft svårt med Motorolas mnemonics men andra kanske trivs bättre med dom...

En bra lösning ser jag som att man skapar en RISC-µC med en emulator som kan köra på en USB-hårdvara, då kan man skapa en universell "µC" och ändå rent faktisk kunde blinka lampor med den, simulera programexekveringen, plattformsoberoende osv.

[Nerre]

Jag undrar om kompilatorer har koll på vad som är
möjligt att utföra smart i alla lägen?

När jag började leka lite med AVR för några år sen (en kille på ABC-klubben satte upp nåt utvecklingskort framför en webbkamera och sen kunde man alltså köra ssh till en maskin där, kompilera, ladda upp programmet och sen se lysdioderna blinka via webbkamera!:) så provade jag att skriva ett enkelt "blinka några LED" i dels assembler och dels C. Tanken var att kolla hur bra kompilatorn optimerade, och det var nästan läskigt hur bra den var på högsta optimering.

Jag jämförde ju den disassemblerade koden från avr-gcc med min egen assembler. Efter att ha bytt register i mitt eget program var koden nästan identisk (bortsett från att C ju har lite inledande uppstartgrejer) när jag körde "ganska bra optimering". På högsta optimeringen så blev alltså C-koden effektivare/snabbare än min assembler (men den blev mer svårtläst på grund upprullade loopar och sånt skit).

Just en sån grej som Icecaps optimering av multiplicering med 10 tror jag faktiskt att gcc fixar, MEN koden måste då vara skriven så att 10 är definierad som en konstant.

[Nerre]

alltså är t.ex. 6502 kanske inte en helt lyckad strategi att utgå ifrån, helt enkelt för att det är snudd på omöjligt att skaffa ett system som baseras på den µC och att skapa ett fungerande system blir dyrt, besvärligt och nära nog omöjligt att få till att fungera utan ett intimt kännedom om µC-system - vilket man ju inte har i det fall.

Kursen har ju en fungerande simulator! Med grafisk display.

Så istället för att behöva köpa hem eller löda ihop ett experimentkort för att kunna blinka med lysdioder så kan du på bara nån minut skriva ihop ett program som blinkar med pixlar på en "display". Första kodexemplet på sidan tänder tre punkter på displayen i olika färger. Och som sagt var, sista exemplet är ett fullt spelbart Masken, skrivet i assembler och med tillhörande förklaringar av hur koden fungerar.