Le problème du VLIW
L'architecture VLIW (pour Very Long Instruction Word) est basée sur un parallélisme indiqué explicitement au niveau du code exécutable. Des instructions n'ayant aucune dépendance entre elles sont regroupées dans des paquets de taille fixe et qui ne peuvent donc en contenir plus d'un certain nombre (par exemple 8). Le processeur VLIW chargera toujours des paquets complets lors du fonctionnement d'un programme. Cette approche déplace la gestion du parallélisme du cœur du microprocesseur vers le compilateur qui traduit dans le code propre à la machine les fichiers sources écrits par les informaticiens. Cela doit permettre de libérer de la place au niveau du silicium du circuit afin de pouvoir y loger plus d'unités de calculs ou de fonctionnalités devant améliorer les performances.
Un problème se pose quand il est question de passer à une nouvelle génération de processeur qui augmente le nombre d'unités de traitement (par exemple en le doublant). Même si on reste compatible avec la taille de paquet précédente, les programmes compilés en tenant compte de celle-ci n'utiliseront toujours que les possibilités qui étaient disponibles dans le matériel antérieur. Il ne faut pas espérer convertir facilement les anciens exécutables en prenant les paquets 2 par 2 et en plaçant leur contenu dans le nouveau format plus grand. En effet, comme le compilateur aura cherché en priorité à les optimiser, il faudrait un miracle pour que dans les centaines de kilooctets d'une application aucun paquet ne dépende de celui qui le précède.
Comment donc faire évoluer le logiciel en même temps que le matériel ? Peut-être en utilisant un "recompilateur" : Un programme qui soit capable d'extraire l'algorithme d'un exécutable et de le recoder pour la nouvelle machine (les instructions élémentaires et le système d'exploitation resteraient compatibles). Mais en ajoutant un utilitaire pour obtenir le logiciel fini on apporte du même coup des risques de bugs supplémentaires, à moins que celui-ci ne soit livré en même temps que le compilateur et utilise strictement les mêmes modules (et encore). Plus sérieux est le danger que, pour une raison quelconque, des erreurs n'aient pas été repérées dans la première version du programme à convertir et qu'elles apparaissent en changeant de format, car pour des logiciels commerciaux dont on ne dispose pas des sources la seule possibilité serait de s'adresser au fournisseur sans garantie de délai.
La solution semble donc se trouver du coté de logiciels libres que chacun peut compiler sur son système. Plus précisément, cela concernerait les applications devant fonctionner à vitesse optimale, les autres pouvant rester au niveau précédent pendant un certain temps sans gêne particulière. Mais là aussi, comment s'assurer qu'un bug resté caché n'apparaîtra pas sans que les informaticiens s'en aperçoivent ? Comment garantir la fiabilité de ces programmes sans s'arracher les cheveux ? Il faudrait une procédure de test de chaque module en utilisant des programmes qui les incluraient, feraient appel aux moindres de leurs fonctionnalités et devraient rendre des résultats standards. Pour accélérer ce travail, il serait possible de baser chaque élément sur des composants logiciels indépendants pour lesquels le temps de réaction serait plus court. De toute façon ce ne serait pas simple.