TTA (transfer-trigered architecture) je jeste jednodussi - ta nema ani adresu, kazda "instrukce" jen otevira propojeni mezi dvema bloky (registry, ALU, pristup do pameti atd.), akce se vyvola tim, ze se do neceho zapise (proto tranfer-trigered). "Instrukce" obsahuji jen cisla zdroju a cilu. Je to jako by byl klasicky procesor programovany primo v mikrokodu a obdobne jako VLIW prenasi paralelizsmus na stranu prekladace/programatora, protoze musi pocitat s latencemi jednotlivych bloku.
Problém je, že u jazyku typu C neurčíš nijak latence instrukcí přistupujících do paměti.
Není znám algoritmus, který by se podíval na zdroják nebo na assembler a s rozumnou přesností určil, která proměnná se bude nahrávat z L1 cache, která z L2 cache a která z hlavní paměti.
Proto mají ty x86 procesory out-of-order vykonávání, protože tohle kompilátor neudělá.
Kdybys chtěl určovat latence kompilátorem, tak bys musel mít just-in-time kompilátor --- kde se to za běhu naměřit dá.
Mimochodem, z tohoto důvodu existuje pár případů, kdy je java rychlejší než C (v podstatě se v té javě nesmí nic alokovat jenom dělat operace už s naalokovanými poli --- pak to JIT může zkompilovat líp než C kompilátor)
A BLEKu, proc to nezkompilovat nejdriv s testem, pak to nechat probehnout nejakymi testy a na zaklade tech testu odhadnout, ktera promenna se bude cist z ktere cache, a pomoci teto informace to pak staticky zkompilovat? Nechces namet na dalsi projekt? ;-)
Jak přesně si to představujete? Cache je víceméně transparentní, až na tu latenci, samozřejmě... Možná by zaangažovat nástroj typu Intel VTune, ale podle mě by v tom bylo docela dost hádání. Buďme rádi, že už máme aspoň těch šestnáct general-purpose registrů! Vivat AMD!
Itanium se potopilo samo (tím, že je přepatlané featurami => drahé a pomalé). Nikdo si nebude kupovat počítač, který je 20x dražší než běžné PC a navíc ještě pomalejší.
No, jak si to predstavuju, copak jsem BLEK, abych resil tenhle problem? :) Ja jenom navrhuji postup, jak obecne dohnat vyhodu JIT kompilatoru proti statickemu kompilatoru tim, ze se ta staticka kompilace provede na zaklade nejake statistiky bezneho chovani programu. Sam BLEK pise, ze se ta latence zmerit da, takze asi vi jak na to, ja o tom nemam tuseni. A ani me to nezajima, protoze vim o mnohem lepsi tride optimalizaci zalozenych na tomto principu, ale nehodlam to zatim nikde sirit, protoze si to chci vyzkoumat sam. :)
To umí gcc pouze pro určení skoků, zda se provedou nebo ne. S cachovaností proměnných by to bylo zajímavé. Kdyby se mezi každým přístupem do paměti četly performance-monitoring-countery, tak by to asi ten program šíleně zpomalilo.
Ale možná by bylo zajímavé udělat tohle:
Pustit si timer a občas z zapnout Trace flag a z trap signálu si číst performance countery (a po několika stovkách instrukcí ho zase vypnout, aby ten program taky mohl běžet). Tím získat profil nejen, kde to nejvíc čeká, ale i na čem to nejvíc čeká (cache apod). Kdybych byl ještě na škole, nebylo by špatný to vypsat jako projekt/diplomku :)