Svenska ElektronikForumet

Något tänkvärt i dessa tider..

Denna kan vara intressant att titta på: http://elektronikforumet.com/forum/view ... 34#p653834

nablaman med sin relädatorn Zusie borde kunna det där med maskinkod.

blueint skrev:Med direkt avkodning finns ju också möjligheten till "olovliga instruktioner" som kan åstadkomma mycket kalabalik internt i processorn. 68000 hade väl några sådana samt Pentium.

68000 har väl inga sådana?
Den drar väl en illegal instruction exception vector, $00010, om den stöter på något okänt vid instruktionsdekodningen, eller tänker jag fel?
Samma vektor som om man kör ILLEGAL instruktionen, dvs $4afc.

Dags att fortsätta, $4e73

blueint skrev:Med direkt avkodning finns ju också möjligheten till "olovliga instruktioner" som kan åstadkomma mycket kalabalik internt i processorn. 68000 hade väl några sådana samt Pentium.

6502 har gott om illegala op-koder. Den använder dessutom inte mikrokod på det klassiska sättet. Det intressanta är att det verkar som att det mostek gjorde för att 6502 skulle vara billig att tillverka också gav resultatet att den blev snabb (räknat per klockcykel)!
Pagetable.com: How MOS 6502 Illegal Opcodes really work

Kostar ju grindar för att en illegal op-kod garanterat skall göra 0, att låta den
gör något spännande odefinierat är gratis. I CPU-ernas barndom var det väl ett
avsiktligt optimeringsbeslut att inte slösa de få grindar man hade på sådan
säkerhet men fanns det på senare flerprocess-/fleranvändar-CPU såsom Pentium
och 68000 var det nog mer en konstruktionsmiss.

Sant.

Vad som är märkligare är väl att 6502 konstruerades med så många instruktioner som tvärhänger processorn. Det borde rimligtvis ha gått att göra instruktionsuppsättningen så att alla op-koder på något sätt avkodats. Å andra sidan är det kanske lika bra att det blir tvärhäng om fel kod körs in i CPU'n.

(Något som borde ha kostat väldigt lite kisel hade väl annars varit att låta en "ivägsprungen" 6502 dra i sin egen reset-tamp, fast det var väl ändå inget som gick att försvara ekonomiskt).

Mikrodatorns ABC tar upp de bitarna såvitt jag minns. Där avhandlas också refresh av dynamiskt RAM, hur grafikkretsarna omvandlar ASCII-koder till bokstäver på skärmen och lite andra såna grejer.

Står på WP att man ekonomiskt bara kunde ha ett par tusen transistorer på chipet
då 6502 konstruerades, så det var nog grinddelning som i mycket styrde hur
op-koderna kom att se ut och definierat och odefinierat fungerade. Syntesverktyg
fanns väl knappt då så det var väl ritbord & klippa och klistra ihop underlag till
etsmasker och annat.

68000 hade 40k transistorer och på Pentium var det väl miljontals.

Är det en skröna när Wikipedia säger att 68000 hade just 68000 transistorer?

(Det låter ju lite småmärkligt, namnet är väl rimligare bara taget från 6800 med en nolla till)

Listan är för övrigt intressant, den säger att det bara var ur-mikroprocessorerna 4004 och 8008 som hade färre grindar och grövre process än 6502, ändå kan man väl säga att 6502 var rätt så jämförbar med 6800 och delvis 8080. (Jag vet inte hur det var med 4004 och 8008, däremot är 8080 inte jämförbar med 6502, utan snarast 8085 är väl vad som kan jämföras eftersom 8085 likt 6502 klarar sig utan diverse kringkretsar, vilket 8080 däremot behöver).

Fanns ju många varianter av 68k, var väl första som låg på 40k...

Annars så tycker jag väl att det är väl
motiverat som minnesregel att tänka att den hade 68k transistorer
och föregångaren 6.8k, att veta vilken 10-potens det handlade om
kan vara nyttig teknisk allmänbildning medans det exakta antalet är
något man inte behöver belasta hjärnan med.

DanG skrev:Edit: Ser att ICECAP har berättat om vedermödorna på ett utmärkt sätt. Som sagt, man lärde sig en hel del, speciellt om CPU etc. var virade och därmed lämpliga för ombyggnad/förbättringar.

Åhhh, härliga forntid ...

Vill Du veta mer, så rekommenderar jag nedanstående länk.
http://en.wikipedia.org/wiki/AMD_Am2900
Flera "stora" datorer byggde på denna kretsfamilj, till vilken man sedan lade diverse diskret logik för att få assemblerinstruktionerna att fungera som avsett.
Detta tog en hel del plats, MODCOMPs CPUer, som jag jobbat mest med, bestod av 1-2 virade s.k. plan.
Se sid 6 på http://www.ddp116.org/modcomp/modcomp.pdf

Det roliga med dessa system var att man lärde sig mycket.

M.v.h DanG

Sådana Datorer använde vi på ASEA då jag började jobba där 1984..... Modcomp Classic II/75. Master Clear, Fill/3, Run...... för att starta

En indirekt förståelse av hur mikrokod och cpu'n fungerar bakom instruktions-setet kan man få genom att studera hur många klock/maskin-cykler en instruktion tar. Normalt brukar det gå 4 klockcykler/maskincykel och en instruktion kan ta 1-4 typ maskincykler. Dessa cykler indikerar ju att något händer under skalet, typ hämta data från externt/internt(snabbare)/ackumulator(ännu snabbare), sedan processa där exvis multiplikation tar flera maskincykler än addition osv.
Vissa operationer tar klockcykler och andra tar maskincykler i anspråk. Och på vissa nyare cpu'er kan det givetvis ske parallellt och med cachning så att cpu'n gissar sig till nästa operation och gör den när det ändå finns en klockcykel över.

Särskilt i äldre cpu'er fanns rätt bra instruktionstabeller där det stod en del av vad som skedde under de olika klock och maskincyklerna. Typ 6802 osv.

Sedan är "Maskinkod" väl själva instruktionerna ("assembler") medan "mikrokod" är dessa del-steg som utförs.

Maskinkod != assemblerkod. Assemblerkod innehåller normalt en hel
del direktiv och villkorlig kod som inte har något med maskinkod att göra.
Maskinkod är enbart de binära koder som hårdvaran kan exekvera.

Mikrokod ligger i en gråzon på gränsen till ren maskinvara...