Thomas S. Iversen wrote:
>>Det er vel lige meget hvad Thomas Schreiber mener en RISC
>>processor er. Det vigtige er vel hvad industrien har defineret
>>RISC til.
>
>
> Jon din internet trold. Giv mig et link til det pdf dokument der beskriver
> hvad "industruen" har defineret RISC til!
>
> RISC er ikke noget fast defineret. Hvad henviser Reduced til? Complexitet af
> de udførte instruktioner? Antallet af instruktioner?
>
> Det er som med alt andet. CISC kan tages til ekstremerne og man kan
> implementere f.eks. en sqrt funktion i cpuen, der fylder lidt, men tager
> AAAALT for lang tid at udføre. I den anden ende kan RISC også
> tages til ekstremerne, hvilket vil give meget volumuniøs kode og kræve stor
> cache. De fleste kommercielle cpuer idag ligger et sted midt imellem de 2
> ekstremer.
Sqrt-eksemplet som du giver, er velvalgt. De to design-principper
adskilles af tilgang. CISC indebærer at man tager en meget bred mængde
af ofte forekommene beregninger og implementerer i selve cpu'en. En
fordel: Den binære-kode kan blive meget kompakt. En anden fordel:
Programmøren behøver ikke selv implementere en række instruktioner. I en
RISC-processor vælger man en anden strategi: Forenkling. Alle
instruktioner som kan sløve cpu'en og kan implementeres af andre og mere
grundlæggende instruktioner, bliver udelukket. Det vil sige at mængden
af instruktioner er meget mindre end det er tilfældet for en CISC-processor.
Betyder det så at det bliver sværere for programmøren at kode til en
RISC-cpu? Både ja og nej. For det første antager RISC-arkitekterne at
alle mennesker i dag skriver software i højniveau-sprog der under
oversættelsen til binær-kode selv sørger for at implementere de mere
komplekse instruktioner. Det betyder at en højniveau-sprogs-oversætter
er sværere at programmere end en ditto til en CISC-cpu. Men det skal jo
kun gøres én gang.
Man kan også sige at Ingeniøren, som designer en RISC-cpu, er doven. Han
overlader nemlig en masse arbejde til datalogerne som skriver oversætterne.
--Martin