Hoofdcategorien
Device Settings

Intel Itanium sneak preview

Door Wouter Tinus, maandag 22 januari 2001 16:09, views: 17.061

EPIC: de oplossing

De nieuwe architectuur moest deze problemen voor een groot deel oplossen, daarnaast moest hij geschikt zijn om zo'n 25 jaar mee te gaan en de schaalbaarheid moest goed zijn. Al snel werd daarom besloten dat de nieuwe standaard gebaseerd moest worden op EPIC: Explicitly Parallel Instruction set Computing. De ideen daarachter zijn ontstaan rond 1980 en draaien vooral om het parallel uitvoeren van instructies en het zo efficint mogelijk gebruik maken van de beschikbare execution units. Een EPIC architectuur is daarom ideaal om de problemen, die op de vorige pagina werden beschreven, op te lossen.

Het is voor een processor ondoenlijk om te bepalen welke instructies elkaar benvloeden. De compiler, het programma dat van programmeertaal machinecode maakt, heeft echter alle tijd van de wereld. De letter 'e' in EPIC staat voor Explicity en dat betekent dat het programma aan de processor vertelt welke delen tegelijk (parallel) kunnen worden uitgevoerd. Een EPIC compiler heeft daarom ook veel meer verantwoordelijkheden dan een x86 compiler. Het is zijn taak om de programmacode grondig te analyseren, te bepalen waar vertakkingen optreden en uit te zoeken welke stukken code tegelijkertijd uitgevoerd kunnen worden.


De compiler kan er natuurlijk niet voor zorgen dat er continu code is om te verwerken en dus zullen ook EPIC processors last hebben van branches. EPIC lost dit op door middel van predication. De processor zet dus niet al z'n geld op n keuze, maar verwerkt beide mogelijkheden tegelijk, zodra bekend wordt welk pad het goede was wordt het andere stopgezet. Stel dat de uitslag van opdracht A bepaald of opdracht B of E moet worden uitgevoerd. In plaats van te gokken worden A, B, C, D, E, F en G de pipeline in gegooid. Zodra A er aan de achterkant uitkomt blijkt dat E de goede opdracht was. Op dat moment wordt het uitvoeren van B, C en D stopgezet en de waarden die uit E, F en G komen worden op de goede plaatsen neergezet. Was echter B, C en D de goede weg geweest had dat geen kloktik meer of minder gekost. De enorme klap van het misgokken wordt hiermee verbannen.

Itanium - Branch codesample

Het kan natuurlijk ook gebeuren dat er tijdelijk geen opdrachten kunnen worden uitgevoerd omdat er gegevens uit het cache, het RAM, of in het ergste geval de harde schijf nodig zijn. EPIC probeert de wachttijden te minimaliseren door middel van speculation. Dit houdt in dat de processor voor hij de gegevens daadwerkelijk nodig heeft al te horen krijgt dat ze binnenkort nodig zijn, zodat hij alvast opdacht kan geven om deze klaar te zetten in het cache. Een nadeeltje aan het vervroegd opvragen van gegevens is dat er tussen het halen en daadwerkelijke gebruiken nog iets kan veranderen, daarom checkt de processor vlak voor het uitvoeren van de opdracht nog even of de waarde wel klopt.

Het resultaat dat uiteindelijk uit de compiler komt rollen zijn instructiebundels, waarin een aantal opdrachten zitten waarvan van tevoren is bepaald of ze tegelijkertijd uitgevoerd kunnen worden zonder elkaar te benvloeden. Daarnaast is wat extra informatie voor de processor zelf toegevoegd over de opdrachten die in de bundel zitten en het eventuele verband dat ze hebben met de volgende en vorige bundel, omdat ook bundels gegroepeerd worden door de compiler. In een bundel kunnen ook extra opdrachten aanwezig zijn, zoals bijvoorbeeld voor speculation. Dit is een totaal andere manier van werken dan x86, die nog het beste te vergelijken is met de VLIW (Very Long Instruction Word) architectuur die door Transmeta wordt gebruikt.

Volgende pagina (Intel's Tahoe architectuur - 4/10)


Inhoudsopgave

VNU Media logo Hosted by True

© 1998 - 2012 Tweakers.net B.V. - Alle rechten voorbehouden - Contact - Jouw privacy - Algemene Voorwaarden

Uitgever van:

Website van het jaar 2011