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