ARM's nye turbo-processor: Femdobler ydeevnen med konstant effektforbrug

Cortex A15 er ARM's quadcore-design, der er beregnet til design i 32 eller 28 nm procesteknologi.

ARM har netop løftet sløret for firmaets nyeste processordesign. Det drejer sig Cortex A15, der er en quadcoreprocessor beregnet til fremstilling i 32 eller 28 nm procesteknologi. ARM designer kun processorer, det fremstiller dem ikke selv, hvorfor det er op til de enkelte licenstagere at vælge, hvilken procesteknologi, de vil anvende.

Derfor er det heller ikke på nuværende tidspunkt muligt at komme med effektforbrug for de endelige produkter, men ARM oplyser, at processoren, der arbejder med fire processorkerner, er beregnet til at arbejde med frekvenser i området mellem 1 og 2,5 GHz.

I pressemeddelelsen taler ARM endvidere om en femdobling af den typiske ydeevne i forhold til eksisterende produkter ? og det er vel at mærke med samme effektforbrug.

Foruden øget ydeevne er der også blevet plads til fornyelser som blandt andet komplet understøttelse af virtualisering, der på længere sigt vil gøre det betydeligt nemmere at fremstille operativsystemer og færdige softwarepakker.

Det vil således være muligt at levere et stykke hardware med en indbygget hypervisor, der giver hardwaren et virtuelt lsg, således at forskellig hardware ser ens ud for applikationerne og operativsystemerne.

Med det nye processordesign går ARM for alvor Intel i bedene mod dets Atom-processor samt mod AMD, der snart forventes at kunne levere en Bobcat-processor, der er beregnet til samme marked, som blandt andet omfatter tavle-pc'er og lignende udstyr, der blandt andet er baseret på Android eller Windows Phone 7.

Med det store frekvensområde, som A15 dækker over, vil den endvidere i de langsommere udgaver kunne anvendes i smartphones, uden at batteriet lider unødigt under det.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Kommentarer (6)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Torben Mogensen Blogger

Man kan vel ikke sige, at det er et skridt tilbage, når man giver flere muligheder i stedet for færre, men det er er bare ikek så stort et skridt frem, som man måske kunne ønske.

A15s lagermodel er selvfølgelig ikke helt det samme som et fladt 64-bit adresserum. Men på servere er det ret almindeligt, at de enkelte processer er ret små, men at der køres mange af dem. Derfor er en begrænsning til 4GB pr. proces ikke en voldsom hindring. Modsat "extended mode" på x86, så er det ikke meningen, at de fleste processer skal bruge hele det fysiske adresserum og derfor lave alle adresseringer som en kombination af et blokregister og et offsetregister,

Men det er klart, at ARM før eller siden må komme med en 64-bit processor (de er sikkert allerede nu ved at udvikle den), så man kan betragte A15 som en midlertidig løsning. Men en ret fornuftig af slagsen.

Personligt håber jeg, at ARM laver en 64-bit arkitektur, som ikke bærer rundt på så meget baggage som f.eks. Thumb2. Bevares, de kan sagtens lave processormodes, der sikrer bagudkompatibilitet, men jeg håber, at 64-bit instruktionssættet laves fra [i]tabula rasa[/i].

  • 0
  • 0
Peter Lund

Nu er tabula rasa sjældent en god idé, heller ikke inden for filosofi ;)

Fx var det en lykke at AMD64 så tydeligt var en x86, trods de ekstra registre og de ekstra 32 bit. MIPS, SPARC og HPPA havde også stor succes med at gå fra 32 til 64 bit med det samme instruktionssæt -- så vidt jeg ved gjorde de ikke meget andet end at tilføje nogle flere load/store-instruktioner (set fra user space, jeg ved godt at det var mere indviklet fra kernel space).

En rigtig god historie i denne sammenhæng (som jeg er sikker på at du kender ret godt) er Data Generals Eagle-serie fra ca 1980. De havde i forvejen nogle 16-bit maskiner (Nova-serien), efterhånden udvidet med diverse sære himstregimser à la physical address extensions men det var ikke godt nok for kunderne mere. De satte så en gruppe i gang som noget skunk works langt væk fra hvor firmaet normalt arbejdede -- plus et lille reservehold til at lave en nødplan.

Dem der Lavede Tingene Rigtigt leverede aldrig (pageable microcode! instruktioner til sortering af BCD-tal!) men nødplanen lykkedes.

Eagle-maskinerne var fuldt bagudkompatible med Nova, de havde bare også 32-bit instruktioner oven i. Et af trickene var at mikrokoden checkede den første instruktion i hver interruptrutine: hvis det var en Nova-instruktion lavede den en 16-bit stakpakke og hvis det var en 32-bit Eagle-stakpakke ;)

Tracy Kidder fik en velfortjent Pulitzerpris for bogen om holdet bag Eagle.

8088/8086 var i øvrigt også noget der blev smækket sammen på forholdsvis kort tid som en stopgap measure fordi deres andre CPU'er enten var for små (8080, 8048, 8085) eller forsinkede (432, som var Lavet Rigtigt). Der var med vilje ikke nogen smarte tricks i arkitekturen og det blev nok dens redning.

  • 0
  • 0
Jacob Christian Munch-Andersen

At udvide en gammel arkitektur frem for at lave en ny har helt nøjagtigt en fordel, bagudkompatibilitet. Når vi snakker ydelse, strømforbrug, produktionspris osv. så er en ny legacyfri arkitektur praktisk talt altid at foretrække. Hvor meget det giver kommer an på hvor skidt det står til med den gamle arkitektur, et moderne x86 instruktionssæt er eksempelvis et rod uden lige skabt af 30 års udvikling uden mulighed for at rydde op undervejs. Især Windows platformen gør det dog praktisk talt umuligt at skifte instruktionssæt.

Problemerne er ikke lige så store for ARM arkitekturen, til gengæld har de fleste kunder også langt lettere ved at flytte fra en arkitektur til en anden end det er tilfældet med x86/Windows, og de gamle processorer vil ikke blive aflivet bare fordi ARM laver en ny arkitektur. Kunderne kan blive på deres nuværende arkitektur så længe de ønsker, og så flytte når de er klar eller har brug for det.

Man kan også forestille sig at der bliver udviklet et kompatibilitetsmodul som kunderne kan vælge til eller fra, ARM giver generelt langt bedre muligheder for individuel tilpasning end de fleste andre arkitekturer, der er normalt bare en stak hyldevarer.

  • 0
  • 0
Log ind eller Opret konto for at kommentere