Hej Den här länkades till på ElektronikForum för ett tag sedan: http://www.cs.colby.edu/djskrien/CPUSim/ Jag har inte testat själv, men det kanske kan vara något att labba med för er som vill göra en egen arkitektur. /P
On 10/10/2013 10:33 AM, Pontus Pihlgren wrote:
Hej
Den här länkades till på ElektronikForum för ett tag sedan:
http://www.cs.colby.edu/djskrien/CPUSim/
Jag har inte testat själv, men det kanske kan vara något att labba med för er som vill göra en egen arkitektur.
Ooh, ser intressant ut! Själv sitter jag och plöjer igenom alla forskningsrapporter jag kan hitta om koddensitet. Jag kommer att ha väldigt ont om minne, så jag vill veta hur man designar en maximalt kompakt instruktionsuppsättning. De flesta rapporterna handlar dock om kodkomprimering, dvs antingen genom att man bara skriver ett jättetråkigt program som packar upp koden lite i taget när den ska köras, eller genom att man sätter en liten låda på minnesbussen eller mellan I-cachen och kärnan som dekomprimerar instruktionsströmmen on-the-fly. Störtlöjligt. De mer relevanta punkterna när det gäller designandet av en instruktionsuppsättning är dessa: * Variabel instruktionslängd, med vanliga instruktioner kodade med färre bittar * Instruktionsformat med korta immediates; de flesta konstanter är bara några bittar långa * De allra vanligaste konstanterna är 0 och 1; det är värt att ha specialinstruktioner för t.ex. ladda 0 och addera 1 * Allmänt en bra ide med specialinstruktioner för vanliga kombinationer, t.ex. push/pop, subrutinanrop, dekrementera-testa-hoppa * Relativ adressering; konditionella hopp t.ex. hoppar oftast bara några instruktioner bort. Små offsets är bra. * Flera adresseringssätt. [Register + offset] är jättevanligt, [register + register] inte. Indirekt adressering är i princip värdelöst. Immediates är jättevanligt. Autoinkrementerande adresseringssätt gör koden märkbart mer kompakt. * Instruktioner ska sätta flaggor så man slipper testinstruktioner * Divisionsinstruktioner hjälper, särskilt i program som skriver ut nummer, eftersom det blir en massa delande med 10 då. Ganska mycket av det här är väl rätt intuitivt, men det har även i de fallen varit rätt trevligt att få se siffror på hur det ser ut på riktiga arkitekturer och med riktig kod. På 8086 är t.ex. i en rapport 28,4% av alla operander minnesoperander, men bara 0,4% använder [reg + reg] för adresseringen. I koden för RSX på PDP-11 är [reg + offset] 17,3% av alla operander, 14,9% är immediate, och 15,2% är olika autoinkrementerande adresseringssätt, men en stor del av de senare är instruktioner som bara använts för att inkrementera ett register med 2, som alltså är ett fall som kanske skulle optimeras. Indirekt adressering är 1%. PDP-11 uppnår för övrigt väldigt hög koddensitet; i en jämförelse av koddensiteten hos handoptimerad assemblerkod på 21 olika arkitekturer vinner PDP-11, följd av CRISv32 (som jag aldrig har hört talas om), AVR och Z80. Alpha är riktigt dålig och Itanium är ett roligt skämt ha ha. På 8080 är 80% av alla hopp inom 127 bytes från hoppinstruktionen, på IBM System/370 är det 50-60%. På System/370 tillåts adressering med [reg + reg + offset], men så mycket som 95% av instruktionerna använder bara ett register. Undantaget är program som gör väldigt mycket arrayvandrande; där sjunker andelen minnesreferenser som bara använder ett register till omkring 80% i de exempel som undersökts av rapporten i fråga. Det är hur som helst värt att spara in bittarna som går till specifierandet av det andra registret och göra offsettet större, för offset av alla storlekar förekommer. Minnesadressering på System/370 är förresten totalt CP, läs om det om ni vill få er ett ta-sig-för-pannan-ögonblick. Hm oj, nu skrev jag mycket mer om det här än jag hade tänkt, och det mesta av det var kanske inte så intressant! :D Jag har snöat in ordentligt och har jättekul. Jag ska designa en skitbra arkitektur! Bjarni
On 10/10/2013 03:53 PM, Bjarni Juliusson wrote:
Hm oj, nu skrev jag mycket mer om det här än jag hade tänkt, och det mesta av det var kanske inte så intressant! :D Jag har snöat in ordentligt och har jättekul. Jag ska designa en skitbra arkitektur!
Det är roligt att läsa. Jag har egentligen inget att tillföra utom det att göra vanliga instruktioner korta är en sorts komprimering. Man kan säkert göra det smart så att avkodning blir enkel, t.ex. "är bitposition 1 satt så behöver man läsa ytterligare en byte, annars inte". Sen tänkte jag föreslå att du läser lite om ARM Thumb, inte för att efterapa thumb, men för att se vilka designval dom har gjort när dom "krympt" den vanliga arm-instruktionsuppsättningen. /P
On 10/11/2013 01:17 PM, Pontus wrote:
Sen tänkte jag föreslå att du läser lite om ARM Thumb, inte för att efterapa thumb, men för att se vilka designval dom har gjort när dom "krympt" den vanliga arm-instruktionsuppsättningen.
Jag ligger steget före serru!
On 10/10/2013 03:53 PM, Bjarni Juliusson wrote:
PDP-11 uppnår för övrigt väldigt hög koddensitet; i en jämförelse av koddensiteten hos handoptimerad assemblerkod på 21 olika arkitekturer vinner PDP-11, följd av CRISv32 (som jag aldrig har hört talas om), AVR och Z80. Alpha är riktigt dålig och Itanium är ett roligt skämt ha ha.
Är det Weaver/McKee-rapporten du syftar på? Dom är inte helt optimala i sin jämförelse där, till exempel så är vaxkoden inte alls särskilt optimerad. PDP11 har dom kört på nån target som inte haft /proc/cpuinfo så det försvann ur koden. Bara mentalt sisådär så borde alltid vax vinna över pdp11 eftersom den senare har en instruktionslängd på minst 16 bitar medan vax har 8. Hm, nu blev jag ju nästan sugen på att handoptimera lite vax-assembler :-) -- R
On 10/11/2013 05:44 PM, Anders Magnusson wrote:
On 10/10/2013 03:53 PM, Bjarni Juliusson wrote:
Är det Weaver/McKee-rapporten du syftar på? Dom är inte helt optimala i sin jämförelse där, till exempel så är vaxkoden inte alls särskilt optimerad. PDP11 har dom kört på nån target som inte haft /proc/cpuinfo så det försvann ur koden.
Japp, det är Weaver & McKees rapport jag syftar på där. Informativa påpekanden; har inte hunnit titta på själva koden än.
Bara mentalt sisådär så borde alltid vax vinna över pdp11 eftersom den senare har en instruktionslängd på minst 16 bitar medan vax har 8.
Jag blev lite förvånad över att VAX inte hamnade bättre till i jämförelsen. Jag pratar inte VAX själv så jag är inte säker på detaljerna, men den arkitekturen har åtminstone nästan alla egenskaper som ger god koddensitet.
Hm, nu blev jag ju nästan sugen på att handoptimera lite vax-assembler :-)
My work is done. Bjarni
On 10/11/2013 11:42 PM, Bjarni Juliusson wrote:
On 10/11/2013 05:44 PM, Anders Magnusson wrote:
On 10/10/2013 03:53 PM, Bjarni Juliusson wrote:
Är det Weaver/McKee-rapporten du syftar på? Dom är inte helt optimala i sin jämförelse där, till exempel så är vaxkoden inte alls särskilt optimerad. PDP11 har dom kört på nån target som inte haft /proc/cpuinfo så det försvann ur koden.
Japp, det är Weaver & McKees rapport jag syftar på där. Informativa påpekanden; har inte hunnit titta på själva koden än.
Jag har gått igenom den nu, och har även skickat lite kommentarer till honom om den :-) Det intressantaste är egentligen lzss-storleken, eftersom den gör samma sak på alla arkitekturer.
Bara mentalt sisådär så borde alltid vax vinna över pdp11 eftersom den senare har en instruktionslängd på minst 16 bitar medan vax har 8.
Jag blev lite förvånad över att VAX inte hamnade bättre till i jämförelsen. Jag pratar inte VAX själv så jag är inte säker på detaljerna, men den arkitekturen har åtminstone nästan alla egenskaper som ger god koddensitet. Ett av problemen här var att han inte kollade bara på hur mycket kod det blev utan hur stor binären blev. Då får man en massa overhead på grund av binärformat och sånt på vax som har ELF, men pdp11 som har a.out får bara 8 bytes overhead typ.
Hm, nu blev jag ju nästan sugen på att handoptimera lite vax-assembler :-)
My work is done.
Jag gjorde det, och kapade bort mer än 10% av kodstorleken med lite enkla handgrepp. Det som gör att i386 fortfarande vinner på lzss är att ladda-och-öka-pekare är en byte på den men flera på vax, och den används flera gånger. I övrigt så blir dom rätt lika. -- Ragge
On 10/15/2013 01:13 PM, Anders Magnusson wrote:
On 10/11/2013 11:42 PM, Bjarni Juliusson wrote:
On 10/11/2013 05:44 PM, Anders Magnusson wrote:
Japp, det är Weaver & McKees rapport jag syftar på där. Informativa påpekanden; har inte hunnit titta på själva koden än.
Jag har gått igenom den nu, och har även skickat lite kommentarer till honom om den :-)
Mycket välartat!
Det intressantaste är egentligen lzss-storleken, eftersom den gör samma sak på alla arkitekturer.
Vilken tur att du är så noggrann och observant; jag har ägnat mig åt att plöja igenom ett par dussin andra rapporter på bredden istället, för att se vad de är överens om. :) Men det verkar hur som helst att slutsatserna är desamma: variabel instruktionslängd, autoinkrementerande adressering, komplicerade instruktioner istället för vanliga sekvenser...
Jag blev lite förvånad över att VAX inte hamnade bättre till i jämförelsen.
Ett av problemen här var att han inte kollade bara på hur mycket kod det blev utan hur stor binären blev. Då får man en massa overhead på grund av binärformat och sånt på vax som har ELF, men pdp11 som har a.out får bara 8 bytes overhead typ.
Ja det är ju lite tveksam metod.
Hm, nu blev jag ju nästan sugen på att handoptimera lite vax-assembler :-)
My work is done. Jag gjorde det, och kapade bort mer än 10% av kodstorleken med lite enkla handgrepp.
Vilka grepp var det mest? * Jag har i alla fall läst lite mer, bland annat en rapport av Flynn, Mitchell och Mulder från 1987, där de jämför en påhittad typisk RISC med olika features tillagda och kod genererad av samma kompilator, med kodgeneratorer skrivna för ändamålet. De pratar mest om minnestrafik och cachning, men det säger också en del om kodens densitet. De kom bland annat fram till att mer än 16 register är slöseri; ökning av antalet register från 8 till 16 på den påhittade RISCen minskade fetch-trafiken med 20%, men när de ökade till 128 register och registerfönster fick de bara 5% till. Datatrafiken minskade med 35% mellan 8 och 16 register, och ungefär 0% hur många ytterligare register de än slängde på. När de däremot lade till minnesoperander till instruktionerna (bara register-register i basversionen) och optimerade kodningen av reg-reg-instruktionerna till 16 bitar istället för 32 (som var den fasta instruktionslängden i basversionen) så vann de 35% fetchtrafik. :) Min skiss till arkitektur har just nu 32 register, men det är av en tillfällighet, för att det passade fint så. Jag överväger att minska det till 16 och använda det frigjorda utrymmet i Williamsröret till nåt annat och den extra bitten i instruktionsorden till fler instruktioner och/eller adresseringssätt. Det trasslar dock till det lite för storleken på immediates och offset, som då halkar ner till 4/8 bitar istället för 5/10 (kort/långt format resp). Ska klia mig en massa i skägget och läsa fler rapporter tills jag kommer på hur det ska vara. Började även lite grann med en sample and hold som behövs för adressering av registerfilen i Williamsminnet. Fick ett förslag på en krets med rör av en snubbe, men han behagade inte svara när jag frågade om han kunde förklara hur den funkade, så jag måste tänka lite mer. :) Nej nu fick jag nog av att skriva. Måste läsa. *poff* Bjarni
On 10/15/2013 02:11 PM, Bjarni Juliusson wrote:
Det intressantaste är egentligen lzss-storleken, eftersom den gör samma sak på alla arkitekturer.
Vilken tur att du är så noggrann och observant; jag har ägnat mig åt att plöja igenom ett par dussin andra rapporter på bredden istället, för att se vad de är överens om. :)
Men det verkar hur som helst att slutsatserna är desamma: variabel instruktionslängd, autoinkrementerande adressering, komplicerade instruktioner istället för vanliga sekvenser...
Med viss modifikation, ja, komplicerade instruktioner kan lätt bli för överarbetade och därför för långa. Om man på en vax till exempel skall kopiera en nollterminerad sträng kan man göra: (insträng i r5, utsträng i r11) locc $0x0,$0xffff,(r5) # 3a 00 8f ff ff 65 # Söker efter 0 i strängen r5 i max 65535 tecken subl2 r5,r1 # c2 55 51# Ta fram stränglängden (ut från locc i r1) movc3 r1,(r5),(r11) # 28 51 65 6b# Kopiera r1 tecken från r5 till r11 Totalt 13 tecken alltså. Om man istället gör en kopiera-och-jämför-loop blir det bara: 1: movb (r5)+,(r11)+ # 90 85 8b # Kopiera och autoinkrementera ssamtidigt bneq 1b #12 fb # En till om vi inte kopierade en nolla 5 tecken nu. På en x86 skulle det vara typ: 1: lodsb stosb jz 1b Ovanstående är 4 bytes.
Hm, nu blev jag ju nästan sugen på att handoptimera lite vax-assembler :-)
My work is done. Jag gjorde det, och kapade bort mer än 10% av kodstorleken med lite enkla handgrepp.
Vilka grepp var det mest?
Ta bort komplexa instruktioner, stoppa ofta använda konstanter i register, använd komplexa adresseringsmod.
Jag har i alla fall läst lite mer, bland annat en rapport av Flynn, Mitchell och Mulder från 1987, där de jämför en påhittad typisk RISC med olika features tillagda och kod genererad av samma kompilator, med kodgeneratorer skrivna för ändamålet. De pratar mest om minnestrafik och cachning, men det säger också en del om kodens densitet.
De kom bland annat fram till att mer än 16 register är slöseri; ökning av antalet register från 8 till 16 på den påhittade RISCen minskade fetch-trafiken med 20%, men när de ökade till 128 register och registerfönster fick de bara 5% till. Datatrafiken minskade med 35% mellan 8 och 16 register, och ungefär 0% hur många ytterligare register de än slängde på.
När de däremot lade till minnesoperander till instruktionerna (bara register-register i basversionen) och optimerade kodningen av reg-reg-instruktionerna till 16 bitar istället för 32 (som var den fasta instruktionslängden i basversionen) så vann de 35% fetchtrafik. :)
Hm, det där är faktiskt rätt bra att ha i bakhuvudet. VAXen liksom Alphan har 16 register, men MIPSen har ju 32. Det är alltså onödigt många då...
Min skiss till arkitektur har just nu 32 register, men det är av en tillfällighet, för att det passade fint så. Jag överväger att minska det till 16 och använda det frigjorda utrymmet i Williamsröret till nåt annat och den extra bitten i instruktionsorden till fler instruktioner och/eller adresseringssätt. Det trasslar dock till det lite för storleken på immediates och offset, som då halkar ner till 4/8 bitar istället för 5/10 (kort/långt format resp). Ska klia mig en massa i skägget och läsa fler rapporter tills jag kommer på hur det ska vara.
Började även lite grann med en sample and hold som behövs för adressering av registerfilen i Williamsminnet. Fick ett förslag på en krets med rör av en snubbe, men han behagade inte svara när jag frågade om han kunde förklara hur den funkade, så jag måste tänka lite mer. :)
Tänkte du köra Williamsminne för registren? Själv har jag snöat in på kondensatorminnen för register. Jag tror det kan bli rätt bra :-) Det gäller bara att få till nåt bra refreshsystem, jag är inte helt klar med det än. Dessutom tror jag att jag har en bra ide hur man bygger latchar för pipelinesteg. För att kunna använda kombinatoriken under hela klockcykeln har man två flipflops, en ut och en in, som togglas emellan varje steg. För varje pipelinebit går det åt 3 ECC91, 2 EAA91, 2 EH90 och en 6AN6 (quad diode). Men jag är inte helt klar än, ritningar kommer snart :-) -- ragge
On 10/15/2013 06:57 PM, Anders Magnusson wrote:
On 10/15/2013 02:11 PM, Bjarni Juliusson wrote:
Men det verkar hur som helst att slutsatserna är desamma: variabel instruktionslängd, autoinkrementerande adressering, komplicerade instruktioner istället för vanliga sekvenser...
Med viss modifikation, ja, komplicerade instruktioner kan lätt bli för överarbetade och därför för långa.
Ja jo, det som indikeras av de rapporter jag har läst är att det är bra med specialinstruktioner för call/ret, push/pop, kanske strängoperationer, även specialopkoder för instruktion + vanlig operand, typ inc, dec, clear. Däremot missar man ju målet att ersätta vanliga sekvenser med förkortningar om man gör förkortningen mer flexibel än sekvensen den ska ersätta och måste koda en massa extra operander och options som sen sällan används.
På en x86 skulle det vara typ: 1: lodsb stosb jz 1b
Ovanstående är 4 bytes.
Fast varken lods eller stos sätter väl flaggorna? Det var en till av sakerna forskningen visade: sätta flaggor är bra, sparar testinstruktioner. Om Intel hade låtit movs sätta flaggorna så hade man kunnat göra: 1: movsb jnz 1b Tre bytes. Hade de också haft en repnz som struntar i cx och tillåts innan movsb så hade det bara varit: repnz movsb Men då börjar det bli frågan om hur många specialfall man vill ha instruktioner för. Specialgrejer för att repetera en enda instruktion känns lite överdrivet. En liknande, mycket praktisk sak som 68000 har specialinstruktion för är dekrementera+testa+hoppa, vilket ju är nåt man gör jätteofta, så där lönar det sig nog.
Hm, det där är faktiskt rätt bra att ha i bakhuvudet. VAXen liksom Alphan har 16 register, men MIPSen har ju 32. Det är alltså onödigt många då...
Ja, och jag har en känsla av att jag har hört det förr: om registren är general-purpose så räcker 8 för det mesta, och 16 räcker så gott som alltid. MIPS16 har 8 GPR plus 2 specialregister (stackpekare, returadress), THUMB drar ner ARMs 16 register till 8.
Tänkte du köra Williamsminne för registren?
Ja, det ser ut så, förutom ackumulatorn. Jag inriktar mig mycket på minimalistisk hårdvara, för jag vet att jag aldrig kommer att orka bygga 16 register i flip-floppar, för det är jättetråkigt. Dessutom kostar det extra pengar som jag inte har, och tar en massa plats. Så efter att ha tittat på olika minnestekniker så bestämde jag mig för att pröva att bygga ett Williamsminne; dels för att antalet komponenter är väldigt litet, dels för att jag har ett lagom litet oscilloskoprör som bara ligger och skräpar, komplett med nätdelar, dels därför att det är så djävla roligt, dels för att det verkar görbart och inte är beroende på att man kan få tag på udda komponenter eller lyckas konstruera mekaniska delar, och dels för att liksom fira 1900-talet! Få saker är så bra representanter för 1900-talsteknologi som Williamsminne. :) Om det går bra bygger jag kanske ett större Williamsminne som primärminne. Har ett betydligt större rör liggande från en vektordisplay, det borde vara elektrostatisk avlänkning i det.
Själv har jag snöat in på kondensatorminnen för register. Jag tror det kan bli rätt bra :-) Det gäller bara att få till nåt bra refreshsystem, jag är inte helt klar med det än.
Det ska bli skoj att se!
Dessutom tror jag att jag har en bra ide hur man bygger latchar för pipelinesteg. För att kunna använda kombinatoriken under hela klockcykeln har man två flipflops, en ut och en in, som togglas emellan varje steg. För varje pipelinebit går det åt 3 ECC91, 2 EAA91, 2 EH90 och en 6AN6 (quad diode). Men jag är inte helt klar än, ritningar kommer snart :-)
Även det ser jag fram emot! Bjarni
On 10/17/2013 01:08 AM, Bjarni Juliusson wrote:
På en x86 skulle det vara typ: 1: lodsb stosb jz 1b
Ovanstående är 4 bytes.
Fast varken lods eller stos sätter väl flaggorna? Det var en till av sakerna forskningen visade: sätta flaggor är bra, sparar testinstruktioner.
Möjligt, jag kollade inte upp det och talar inte x86-assembler flytande :-)
En liknande, mycket praktisk sak som 68000 har specialinstruktion för är dekrementera+testa+hoppa, vilket ju är nåt man gör jätteofta, så där lönar det sig nog.
Jo, och vax har ett gäng såna också som kan vara mer eller mindre bra ibland :-) sobgeq/sobgtr/aobleq/aoblss - sub/add one and branch if less than or equal (heltal) acb - add, compare and branch nåt till ett tal av valfritt format
Hm, det där är faktiskt rätt bra att ha i bakhuvudet. VAXen liksom Alphan har 16 register, men MIPSen har ju 32. Det är alltså onödigt många då...
Ja, och jag har en känsla av att jag har hört det förr: om registren är general-purpose så räcker 8 för det mesta, och 16 räcker så gott som alltid. MIPS16 har 8 GPR plus 2 specialregister (stackpekare, returadress), THUMB drar ner ARMs 16 register till 8.
Hm, pdp11 har 7 gpreg + pc, och där har man alltid ont om register. Föralldel kommer ett moment till in här: när man har tal som sträcker sig över flera register, då så har man ju i princip bara hälften. Vanligt på x86 också när man emulerar 64-bitarstal.
Tänkte du köra Williamsminne för registren?
Ja, det ser ut så, förutom ackumulatorn. Jag inriktar mig mycket på minimalistisk hårdvara, för jag vet att jag aldrig kommer att orka bygga 16 register i flip-floppar, för det är jättetråkigt. Dessutom kostar det extra pengar som jag inte har, och tar en massa plats. Så efter att ha tittat på olika minnestekniker så bestämde jag mig för att pröva att bygga ett Williamsminne; dels för att antalet komponenter är väldigt litet, dels för att jag har ett lagom litet oscilloskoprör som bara ligger och skräpar, komplett med nätdelar, dels därför att det är så djävla roligt, dels för att det verkar görbart och inte är beroende på att man kan få tag på udda komponenter eller lyckas konstruera mekaniska delar, och dels för att liksom fira 1900-talet! Få saker är så bra representanter för 1900-talsteknologi som Williamsminne. :)
Om det går bra bygger jag kanske ett större Williamsminne som primärminne. Har ett betydligt större rör liggande från en vektordisplay, det borde vara elektrostatisk avlänkning i det.
Hm, hur skall du göra för att känna av förändringen av en bit? Klistra aluminiumfolie på framsidan röret, eller? :-) Jag tycker det verkar som en utmaning med ett sånt minne.
Själv har jag snöat in på kondensatorminnen för register. Jag tror det kan bli rätt bra :-) Det gäller bara att få till nåt bra refreshsystem, jag är inte helt klar med det än.
Det ska bli skoj att se!
Jag tror det kan bli riktigt bra faktiskt. Dessutom så tror jag det går att göra en bra cache med sånt minne också :-) Det är dock två saker som jag inte är klar på riktigt än, det blir nog empiriska tester för det: 1) Kondensatorernas kapacitanser och dess påverkan. Alltså hur mycket läcker en konding och hur ofta behöver man refresha för ett visst värde. 2) Diodtyp att använda. Finns det för mycket läckströmmar i halvledare så att man måste ha EAA91 istället?
Dessutom tror jag att jag har en bra ide hur man bygger latchar för pipelinesteg. För att kunna använda kombinatoriken under hela klockcykeln har man två flipflops, en ut och en in, som togglas emellan varje steg. För varje pipelinebit går det åt 3 ECC91, 2 EAA91, 2 EH90 och en 6AN6 (quad diode). Men jag är inte helt klar än, ritningar kommer snart :-)
Även det ser jag fram emot! Jag också :-) Måste vinterställa husvagnen först bara så finns det lite byggtid sedan...
-- R
Hej Det är mycket roligt att följa eran diskussion. se nedan för en fråga också. On Thu, Oct 17, 2013 at 01:03:48PM +0200, Anders Magnusson wrote:
Hm, pdp11 har 7 gpreg + pc, och där har man alltid ont om register.
Hur menar du då? När du skriver assembler eller när du skriver registerallokerare för en kompilator? Jag har inte så stor vana att skriva assembler (än mindre PDP-11 assembler), men jag föreställer mig att det är mer pyssel när man skriver för hand. /P
On 10/17/2013 01:45 PM, Pontus Pihlgren wrote:
Hej
Det är mycket roligt att följa eran diskussion. se nedan för en fråga också.
On Thu, Oct 17, 2013 at 01:03:48PM +0200, Anders Magnusson wrote:
Hm, pdp11 har 7 gpreg + pc, och där har man alltid ont om register. Hur menar du då? När du skriver assembler eller när du skriver registerallokerare för en kompilator? I princip båda. Registerallokatorn är generell så den gör ju bara vad den är tillsagd, men problemet är att man behöver ett gäng variabler som har lång livslängd och ett gäng variabler för att evaluera uttrycken.
...sen kanske man inte skall räkna sp som generellt register heller även om det är det, men man vill ju normalt ha kvar informationen i det registret också i funktionen.
Jag har inte så stor vana att skriva assembler (än mindre PDP-11 assembler), men jag föreställer mig att det är mer pyssel när man skriver för hand.
Det är svårare att göra saker i assembler eftersom det inte ger samma överblick. Och har man gjort en bra kompilator så borde det inte gå att hitta nåt specialfall som är optimerbart efteråt heller eftersom man har samma kunskap när man implementerar den :-) -- Ragge
On 10/17/2013 01:03 PM, Anders Magnusson wrote:
On 10/17/2013 01:08 AM, Bjarni Juliusson wrote:
Hm, pdp11 har 7 gpreg + pc, och där har man alltid ont om register. Föralldel kommer ett moment till in här: när man har tal som sträcker sig över flera register, då så har man ju i princip bara hälften. Vanligt på x86 också när man emulerar 64-bitarstal.
Jag har programmerat en del assembler på x86, och det har inte varit dubbelbreda data som har ställt till det för mig, utan snarare att alla register är special purpose på x86. >:| På PDP-11 kan jag tänka mig att man oftare använder dubbelbreda tal eftersom de bara är 16 bitar annars. Men OK, som sagt, det ser ut att bli 32 register i min maskin, mest för att det inte är svårare än 16 och jag förmodligen vill ha 5 (och 10) bitars fält i instruktionerna eftersom det är samma fält som kodar immediates och hoppoffset, hellre än 4 (och 8) bitars fält.
Hm, hur skall du göra för att känna av förändringen av en bit? Klistra aluminiumfolie på framsidan röret, eller? :-)
Jag gjorde ett enkelt test med en liten bit kopparplåt som jag lade på framsidan av röret och tryckte en oscilloskopprob mot, och då kunde jag se pulserna som kom när jag svepte på skärmen. Återstår att se om det går att få det tillräckligt tätt mot skärmen med likadan plåt över hela skärmytan (har några små rektangulära bitar) för att få tillförlitlig amplitud på pulserna överallt. Aluminiumfolie låter lite sådär, både ömtåligt och svårt att hålla pressat mot skärmen, och olödbart. Hellre nån tunn kopparplåt/folie då, går väl att köpa. Stod inte specifikt om det i de rapporter jag läst (Williams & Kilburns skrev ett par), så det enda jag vet om hur det gjordes är att det är en metallplatta, ospecifikt hurdan den ska vara.
Jag tycker det verkar som en utmaning med ett sånt minne.
Ja! En utomordentligt bra utmaning! Bjarni
On 10/17/2013 02:38 PM, Bjarni Juliusson wrote:
Hm, hur skall du göra för att känna av förändringen av en bit? Klistra aluminiumfolie på framsidan röret, eller? :-)
Jag gjorde ett enkelt test med en liten bit kopparplåt som jag lade på framsidan av röret och tryckte en oscilloskopprob mot, och då kunde jag se pulserna som kom när jag svepte på skärmen. Återstår att se om det går att få det tillräckligt tätt mot skärmen med likadan plåt över hela skärmytan (har några små rektangulära bitar) för att få tillförlitlig amplitud på pulserna överallt. Aluminiumfolie låter lite sådär, både ömtåligt och svårt att hålla pressat mot skärmen, och olödbart. Hellre nån tunn kopparplåt/folie då, går väl att köpa. Stod inte specifikt om det i de rapporter jag läst (Williams & Kilburns skrev ett par), så det enda jag vet om hur det gjordes är att det är en metallplatta, ospecifikt hurdan den ska vara.
Jag tror jag har sett ett foto på BESK där man kan se fronten på williamsröret med en massa lysande fyrkanter. Men jag minns inte om det var för att fronten var borta eller att dom hade nåt galler eller nåt för avläsningen.
Jag tycker det verkar som en utmaning med ett sånt minne.
Ja! En utomordentligt bra utmaning!
Lycka till! -- Ragge
On 10/17/2013 10:56 PM, Anders Magnusson wrote:
Jag tror jag har sett ett foto på BESK där man kan se fronten på williamsröret med en massa lysande fyrkanter. Men jag minns inte om det var för att fronten var borta eller att dom hade nåt galler eller nåt för avläsningen.
Annars var den vanliga metoden att man hade ett separat visningsrör. Galler kanske funkar, vet ej.
On 10/18/2013 01:21 PM, Bjarni Juliusson wrote:
On 10/17/2013 10:56 PM, Anders Magnusson wrote:
Jag tror jag har sett ett foto på BESK där man kan se fronten på williamsröret med en massa lysande fyrkanter. Men jag minns inte om det var för att fronten var borta eller att dom hade nåt galler eller nåt för avläsningen.
Annars var den vanliga metoden att man hade ett separat visningsrör. Galler kanske funkar, vet ej. Inte omöjligt att det var så, jag saknar som sagt kunskaper här :-)
Finns förresten ett katodstrålerör ute på Tradera nu för 49 kronor: http://www.tradera.com/item/340200/191367257/my13-38-projektionsror-elektron... Om du behöver ett? :-) -- Ragge
On 10/18/2013 01:33 PM, Anders Magnusson wrote:
Finns förresten ett katodstrålerör ute på Tradera nu för 49 kronor: http://www.tradera.com/item/340200/191367257/my13-38-projektionsror-elektron...
Anodspänning 50kV, magnetisk avlänkning. Nej tack. :)
On 10/15/2013 01:13 PM, Anders Magnusson wrote:
On 10/11/2013 11:42 PM, Bjarni Juliusson wrote:
On 10/11/2013 05:44 PM, Anders Magnusson wrote:
Japp, det är Weaver & McKees rapport jag syftar på där. Informativa påpekanden; har inte hunnit titta på själva koden än.
Jag har gått igenom den nu, och har även skickat lite kommentarer till honom om den :-)
Mycket välartat! Han var mycket nöjd över att få kommentarerna och har också uppdaterat
On 10/15/2013 02:11 PM, Bjarni Juliusson wrote: på webben nu. Nån dag jag har tråkigt så får jag sätta mej och optimera mera :-) -- Ragge
On 11/04/2013 07:34 PM, Anders Magnusson wrote:
Han var mycket nöjd över att få kommentarerna och har också uppdaterat på webben nu. Nån dag jag har tråkigt så får jag sätta mej och optimera mera :-)
Jag har nog i princip läst nog med forskning nu. 42 rapporter plus en översikt över ytterligare ett gäng rapporter. De allra flesta innehöll inget av värde. Funderar lite på vad som är nästa steg. Kanske att själv samla ihop lite statistik på adresseringssätt med mera från nån sorts assemblercorpus. Sen behöver jag tugga igenom alla mina anteckningar och koka ihop nån sorts total visdom. Sedan får jag väl... skriva testbakändor till nån kompilator. Nä urk, testar nog att optimera assembler för lite olika varianter av instruktionsuppsättningen istället. En hel del jobb kvar hur som helst innan jag kan spika arkitekturen. Bjarni
participants (4)
-
Anders Magnusson -
Bjarni Juliusson -
Pontus -
Pontus Pihlgren