Intel vil gøre multicore spiselig for embedded-udviklerne

Wind River og Intel vil sammen sende multicore-processorerne ind på embedded-udviklernes territorium. Det er hidtil gået for langsomt med at få teknologien udbredt, mener de to. Dansk udviklingshus ser et potentiale på længere sigt.

Intel og Wind River går nu sammen om at få embedded-udviklernes øjne op for multicore-processorerne. Det skriver Wind River på sin hjemmeside.

Wind River, der står for Wind River Linux-distributionen og en række software-værktøjer til embedded-verdenen, og Intel vil levere optimerede multicore-løsninger til embedded-markedet ved at samarbejde om blandt andet forskning, udvikling og markedsføring.

Indtil videre er overgangen fra singlecore til multicore blevet ved snakken i alt for mange udviklingsafdelinger, og de to producenter tager deres del af skylden for, at udbredelsen af processorer med flere kerner har hængt i bremsen.

»Det er gået for langsomt med at acceptere multicore-teknologien, fordi hardware- og software-producenterne ikke har samarbejdet på dette niveau tidligere,« siger markedsføringschef John Bruggeman, Wind River.

Wind River og Intel vil fokusere på fire punkter, der skal lette overgangen til multicore-processorer.

For det første vil de optimere Wind River VxWorks og Wind River Linux til Intels embedded-processorer. For det andet skal der ske en optimering af Wind Rivers hypervisor-teknologi til Intel-processorer, hvilket omfatter udnyttelse af Intels virtualiseringsteknologi.

Derudover skal udviklingsværktøjerne arbejde bedre sammen for bedre at kunne udnytte multicoreteknologien, ligesom Intels compiler skal integreres i Wind Rivers multicore software-platform til Intels processorer.

Hos det danske udviklingshus Axcon hilser man samarbejdet velkommen, uden dog af være blæst bagover af benovelse.

»Jeg kan absolut genkende det her med, at det er gået lidt trægt for multicore at finde indpas i embedded-segmentet, og det hænger nok sammen med, at det ofte ikke er den optimale løsning bare at smide flere cores efter opgaven, når det handler om embeddede løsninger,« siger medejer af Axcon, Rolf V. Østergaard.

»Ofte kan det for eksempel være en FPGA og en singlecore-processor, der er det mest optimale til opgaven,« uddyber Rolf V. Østergaard.

Han tvivler på, at samarbejdet mellem Intel og Wind River vil have den store betydning på kort sigt, men ser et potentiale længere fremme i horisonten.

»På den lange bane er det absolut en fornuftig og interessant satsning. Overgangen fra singlecore til multicore kommer lige så stille og roligt. Når problemerne begynder at kalde på meget processeringskraft, så kan det i stigende grad indbefatte multicore-cpu'er,« siger Rolf V. Østergaard.

Samarbejdet mellem Intel og Wind River er sat i søen, og i første omgang vil Intel og Wind River fokusere på blandt andet rumfarts-, forsvars- og medicinal-industrien.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Kommentarer (2)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Ville Witt

Ada har den understøttelse der skal bruges... Hvis ikke man er helt med på hvorfor jeg nævner det, og er træt af at høre om parallelisme som noget nyt, skal man vist google lidt... 16/32/64/128 bit? Fri mig! Fortæl hvad du skal bruge og så skal compileren nok selv finde ud af det - eller brokke sig hvis man ikke har så mange bit. Ja, det bliver ikke brugt særlig meget længere.

Software engineering må da være særligt accepteret mellem software ingeniører - alligevel er der mange der ikke har hørt om dette demokratisk konstruerede sprog som også er et ISO sprog (og den er frit tilgængeligt, modsat normale ISO standarder)

  • 0
  • 0
Jens Madsen

Ved embeddes software, er det sjældent hastigheden som er problemet - softwaren udvikles ikke til at "tære" på resourcerne, da formålet er at udvikle billigt hardware, som kan placeres i et typisk produkt.

At udvikle flertrådet, kan være en fordel applikationsmæssigt. Men sprog der håndterer det, og kan køre på en single-core processor, vil ofte være oplagt, da udgifterne holdes minimale, og der ikke er brug for kraftige CPU'er. Er der brug for hurtig elektronik, vil det lægges i en FPGA.

Det er mange sprog, der supporterede flere tråde. Du kan også selv skrive dine routiner. Højnivau sprog, såsom C++, har ofte en relativ simpel oversætter, der kun kræver visse CPU-registre huskes mellem C++ linierne. Det betyder, at ved task skift, er ikke nødvendigt at gemme alle registre, såfremt koden er indenfor et C++ oversat segment. Task skift, kan gøres meget simpelt, ved at gemme de nødvendige registre, som ikke må ændres, og herefter skifte stackpointeren, til stackpointeren for den nye process. Den vil så poppe registrene, så der fortsættes med værdierne for denne process. I de fleste tilfælde fungerer dette. Hvis der er software der ikke er skrevet til multitasking, skal det oftest holdes i en bestemt tråd. Ovenstående virker eksempelvis meget fint i DOS, men alle dos processer, skal holdes i hovedtask'en. Typisk, vil du lave en hovedtask, som indeholder DOS processerne, og som så får ordre fra de andre tasks. I princippet, behøver den ikke, at udføre noget software, andet end at stå for kommunikation med dos. På den måde, kan de resourcer du ønsker skal multitaske i dos, sagtens multitaske.

Hvis du har brug for task-skift i interrupts, f.eks. for tidsopdelt multitasking, så bliver du nød til, at gemme alle registre, inden du udfører task skiftet. I sprog som C++, vil dette ske automatisk, fordi interrupt procedurer gemmer registrene. Et sådant skift, tager dog flere resourcer, fordi den skal gemme alle registre, og poppe dem igen, når den skifter til nyt task.

Det er meget nemt, at lave en sådan task-skift rutine, til en microcontroler, hvis du programmerer i C. Typisk, skal du bare ændre stackpointeren, og sikre de rette registre er gemt først. Nogle programmeringssprog, gemmer stackpointeren i BP registret, for at justere ved return, og så sker ikke meget ved at ændre SP i en rutine. Så skal BP registret ændres i stedet.

Normalt, er det "overkill", at bruge hardware resourcer for at multitaske. Hardwaren, klarer kun et begrænset antal processer. Har du styr på stakken, og ved hvor meget dine rutiner bruger, kan du programmere et meget stort antal task, ned i en meget lille embedded CPU. Idéen, med at bruge en processor, der kan afvikle to, eller 8 tasks, er derfor meget lidt brugbar, med mindre der er CPU tunge opgaver, som ikke egner sig bedre for en FPGA implementering.

Softwaremæssigt, er det stadigt algorithmer som tæller. En faktor to, eller 8, ved at bruge flere tasks, giver ikke noget. Det, som er vigtigt, er at udforske de rette algorithmer, så man ikke anvender en O(N) algorithme, hvor der kunne anvendes O(log(n)) algorithmer. Meget ofte, skyldes programmers "tunge" opførsel, at der anvendes O(n) algorithmer, til søgning, sortering, find, i stedet for O(log(n)).

Med overvejede algorithmer, har man sjældent brug for ekstremt hurtige processorer, til embeddede løsninger. Hvis der er brug for noget hurtigt, skal det være ekstremt hurtigt - og så vælges FPGA'er, eller deciderede skrædersyede chips.

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