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