Nee, anders zou iedereen nog met het supersimpele ontwerp uit 1980 werken, maar dan op hogere klok en op een kleiner procede gebakken.
Een deel van je verhaal klopt en een deel van je verhaal klopt niet, zo is een ontwerp uit 1980 (en eerder!) niet alleen maar simpel. Het ontwerp kun je nog wel simpel noemen als je kijkt naar iets als de on-chip cache, die werd namelijk toen niet gebruikt, maar als je kijkt naar de geïmplementeerde instructies dan is een processor uit 1980 juist complex. Het idee was namelijk dat je complexe zaken beter door de hardware kon laten uitvoeren, zodat de assembler simpel kon blijven en de programmeur met weinig instructies toch heel erg krachtige zaken kon laten gebeuren. Anno 2010 is die complexiteit bij de x86-series juist een belasting en zolang Intel (en AMD) deze niet loslaat zal er altijd enige (nodeloze) ballast meegesleept worden.
Een ARM-processor is dan wel simpel als je kijkt naar de aanwezig instructies (waarbij ik me voor de vergelijking t.o.v. x86 even beperk tot de integer-instructies en FPU's/multimedia-extensies laat voor wat ze zijn, maar dat wordt opgevangen door de compilers. Inmiddels wordt er, behoudens zeer reken-intensief werk, namelijk niet meer in assembler geprogrammeerd. Door heel slim om te gaan met de aanwezige ruimte voor instructies, heeft de ontwerper een redelijk elegante instructieset weten ner te zetten.
Een ander verschil tussen de x86-serie en de ARM serie is het verschil dat je alle instructies op een ARM conditioneel kunt uitvoeren (of juist niet uitvoeren natuurlijk), terwijl je op een x86-serie beperkt bent tot het conditioneel uitvoeren van sprongen (JMP of
Branch instructies). Doordat je op een ARM alle instructies wel/niet uit kan laten voeren [afhankelijk van de processorvlaggen) heb je niet direct een branch-predictor nodig of kun je met een simpelere branch-predictor werken - een sprong is nu eenmaal een kostbare operatie die zaken als een pipeline (en eventueel cache) weer "leeg" maken en deze moeten weer wel gevuld worden.
Maar je moet ook blijven innoveren, want de trucs die werkten op een 16 MHz chipje werken doorgaans niet ideaal meer op 1 GHz (waar Intel bv achterkwam met de P4/Netburst).
Juist het ontwerp van de P4 toonde pijnlijk aan dat de x86-instructieset op bepaalde punten gewoon niet slim opgezet was. Als ik me goed herinner had de(ze) P4 namelijk een erg lange pipeline en die moet wel iedere keer gevuld worden als je een sprong maakt - de software was juist geschreven op een veel kortere pipeline en dus ging er veel tijd verloren na iedere sprong en was een 1GHz processor dus mogelijk trager dan een 250 toto 500 MHz processor met een veel kortere pipeline - voor dezelfde soort code uiteraard. Als de code weer aangepast wordt en dus voor de P4 geschikt gemaakt kan de software weer veel sneller worden.
Juist het grote verschil (in dit geval voor wat betreft de pipeline) t.o.v. de eerdere processors zorgde dus voor een "minder goed" werkende Intel Pentium 4.
En aangezien de komende tijd verwacht wordt dat het segment waar de meeste cpu's worden verkocht niet meer de PC markt is, maar de netbook/tablet/smartphone markt, is dit erg interessant: hier wordt de grote slag tussen PC gigant Intel versus de grote jongens uit de embedded/telefoonmarkt uitgevochten.
Als Intel niet los komt van de bagage uit het verleden en dus onbeperkte compatibiliteit na blijft streven, zal men altijd op power-efficiency op een achterstand blijven - naar mijn mening uiteraard.
Het probleem dat Intel hierbij heeft is dat de consument snel verwacht dat op een x86-notebook/tablet MS-Windows draait en
bijna alle Win32-toepassingen die men kan bemachtigen zitten ze hier ook met een probleem. Als ze de compatibiliteit met het verleden loslaten hebben ze geen voordeel meet t.o.v. ARM (en andere embedded processor-fabrikanten) en moeten ze dus nog harder hun best doen om een deel van de markt te veroveren.
N.B. Bedenk ook dat je in de meeste gevallen helemaal niet puur de beste performance-per-watt wilt - maar tot op zekere hoogte gewoon de beste performance. Of het laagste verbruik. Of de laagste prijs.
Nu telefoons meer en meer smartphones worden en consumenten verwachten dat ze lang op een batterij-lading kunnen werken, maar ook filmpjes e.d. kunnen bekijken is een hoge(re) performance per Watt nog steeds relevant.
Als je slechts 1 dag met een telefoon kan werken en deze moet opgeladen worden, dan is dat minder fijn dan wanneer je 5 dagen met een telefoon kan werken - bij eenzelfde soort gebruikt bedoel ik dus...
Als Intel niet los komt van de bagage uit het verleden en dus onbeperkte compatibiliteit na blijft streven, zal men altijd op power-efficiency op een achterstand blijven - naar mijn mening uiteraard.
Maar dat geldt uiteraard ook voor de ARM instructieset uit 1983. Er zijn sindsdien heel wat architecturen gekomen en gegaan (IA64 was de laatste uitdager), en zowel x86 als ARM zijn beide flexibel genoeg gebleken om zich telkens weer te handhaven. Uiteindelijk moet je ook niet teveel waarde hechten aan een instructieset - dat is uiteindelijk alleen maar een interface bovenop het onderliggende silicon. Instructiesets kunnen uitgebreid worden, of versimpeld - en dat doen de bedrijven erachter dan ook.
Als Intel niet los komt van de bagage uit het verleden en dus onbeperkte compatibiliteit na blijft streven, zal men altijd op power-efficiency op een achterstand blijven - naar mijn mening uiteraard.
Maar met Moorestown Atom heeft nu al Intel geen power-efficiency achterstand meer. De vraag is alleen of het commercieel gaat werken: willen smartphone bouwers wel aan x86? Ze zijn ARM gewend, alle huidige software zou geport moeten worden, of er moet allerlei desktopsoftware voor kleine schermpjes worden omgebouwd. Ik denk dat Intel het moeilijk gaat krijgen om x86 naar smartphones te krijgen, niet omdat hun cpu's zo slecht zijn, maar vanwege de achterstand op softwaregebied. Tablets zijn de enige waar het veld nog open ligt. Bij netbooks heeft Intel nu 100% marktaandeel, dat kan alleen maar omlaag.
[Reactie gewijzigd door Dreamvoid op woensdag 8 september 2010 01:12]
x86 en ARM zijn beiden al redelijk op leeftijd, maar x86 draagt meer overtollige bagage mee uit het verleden (om er een paar te noemen: realmode, 16-bit protected mode, BCD instructies, string-instructies).
De originele ARM-instructieset is maar beperkt van "voortgaand inzicht voorzien", hij was gewoon direct erg goed. De belangrijkste "fout" die er in zat was dat de adresruimte beperkt was, inmiddels reeds lang gecorrigeerd.
Wel zijn er natuurlijk vele instructies aan toegevoegd voor allerhande toepassingen.
[Reactie gewijzigd door dmantione op woensdag 8 september 2010 08:36]
Kleine voetnoot: de Cortex core kan geen ARM instructies uitvoeren! De Cortex maakt gebruik van de 16 bits ARM-thumb instructieset.
Kleine voetnoot: de Cortex core kan geen ARM instructies uitvoeren!
Dat leek me sterk en even zoeken leverde het volgende op voor de Cortex-A9:
ISA Support:
- ARM
- Thumb®-2 / Thumb
- Jazelle® DBX and RCT
- DSP extenstion
- Advanced SIMD NEON™ unit (Optional)
- Floating Point Unit (Optional)
Bron: http://www.arm.com/produc...rs/cortex-a/cortex-a9.php
De Cortex-A9 kan dus wel gewoon de 32-bit ARM instructies uitvoeren (ware het niet dat de legacy 26-bits adressering uit 1983 niet meer ondersteund wordt, maar alleen de 32-bit adressering die sinds de ARM6 (uit 199x) aanwezig is...
"Bij netbooks heeft Intel nu 100% marktaandeel, dat kan alleen maar omlaag."
Oa. HP heeft/had netbooks met AMD-processors. Juist de markt van netbooks is het slagveld, omdat daar alle markten bijeen komen (laptops, tablets, e-readers, smartphone).
OK strikt gezien niet 100%, maar wel heel dichtbij. AMD-based nettops zijn tot nu toe commercieel niet succesvol, vrijwel alle verkochte netbooks zijn Atom-based (of Celeron/Pentium CULV, maar zijn dat nog netbooks?). Leuk voor Intel, maar dat betekent dat het alleen maar slechter kan worden. AMD komt met de nieuwe generatie, ARM gaat het proberen.
Omgekeerd is het natuurlijk in de smartphone/tablet markt - Intel heeft nu 0% marktaandeel, slechter wordt het niet.