[fantoibed]

Originariamente inviato da ^TiGeRShArK^

Il "software" x il code morphing è dunque contenuto nella ROM.
Non mi risulta ke nel CELL sia stato utilizzato un qualsiasi sistema anke lontanamente paragonabile a quello utilizzato nel Crusoe x la traduzione al volo del codice x86 in codice VLIW.

E' più probabile che venga implementato un sistema analogo ma con con traduzione di codice PowerPC-to-PowerPC come avviene nei processori sperimentali della IBM "BOA" e "DAISY" sviluppati dallo stesso team che sta sviluppando Cell. Da http://www.research.ibm.com/people/m.../2002_wced.pdf

[...]While BOA uses special-purpose hardware support in the form of the checkpointing and rollback facilities for the architecting of precise exceptions, the DAISY uses in-order software-managed commit operations. This allows to take exceptions without rolling back the processor state to the previous checkpoint by determining the corresponding original program point for any optimized trace fragment.
To ensure correct correspondence of the program state between the optimized code fragments and the original program, DAISY has to compute the entire state and commit it in original program order. Because DAISY was targeted at wide high-performance VLIW architectures [27], this did not result in performance degradation. Later work extends this approach to allow for the elimination of dead state during the optimization of trace fragments [28, 29], and thus allows to perform more aggressive optimization of trace fragments on architectures with more limited issue bandwidth, such as for PowerPC-to-PowerPC dynamic optimization.
The present approach is different from the DIF approach of Nair and Hopkins [30], and trace processors [31]. By choosing to implement the trace formation and scheduling in software, BOA can generate perform more extensive profiling to determine which trace paths are frequently executed, assemble longer traces, perform more aggressive optimizations and generate better schedules. Also, the underlying hardware only has to support a single execution mode whereas DIF and trace processors require almost three machines: a frontend processor used when executing normal code which has not been collected and preprocessed, a system for preparing, cracking and pre-scheduling the traces to be stored in the trace cache, and the execution engine optimized for executing code from the trace cache.
Our trace-based dynamic optimization is related to the idea of optimizing for the most likely execution path described by Fisher [32]. Trace scheduling requires to estimate the likelihood of a given path being executed and thus requires information about the runtime behavior of programs. Modern compilation systems attempt to address this issue by collecting execution profiles to be used by the compiler. Alas, this profile-directed feedback approach does not allow to optimize the program for different execution profiles according to specific workloads, or for phased program behavior. Unlike the static compilation techniques assumed in this work, dynamic optimization profits from the ability to collect and process profile information at runtime and to react to execution profile changes.

Ho citato il Transmeta perché è sicuramente più conosciuto come processore VLIW rispetto al DAISY. D'altra parte mi vien difficile pensare che S/T/I sviluppino una CPU simile al DAISY come concezione di fondo e decidano di non utilizzare un software di ottimizzazione dinamica già scritto per il DAISY...