Pour prendre un énorme coup de vieux, référence au premier ordinateur qui a vu mes débuts hésitants de programmation : https://en.wikipedia.org/wiki/IBM_1620 .
En Fortran déjà à l'époque ! Puis j'ai appris l'assembler (qui s'appelait le SPS), et je suis tombé dans la marmite à un point tel que, même à la retraite aujourd'hui, je commets encore passablement de lignes en C.
Il y a un groupe de vieux nostalgiques dans mon genre ( à l'époque, l'informatique, c'était le Far West, il fallait tout inventer) qui s'amusent à simuler la 1620 (on disait la et pas le) : http://www.jowsey.com/java/sim1620/.
Je ne sais pas ce qui me retient de me joindre à eux (peut-être java, MDR), parce que, je me souviens encore très bien du SPS et du fonctionnement interne du CPU.
En cours d'exécution du programme, on pouvait, pour débugger, aller, par un bouton hardware, d'instruction en instruction, voire pas à pas à l'intérieur des différents cycles machine (lecture, décodage, exécution) tout en examinant l'état des registres internes. Bref, le pied intégral pour les bidouilleurs.
Et ne parlons pas des codes instructions que l'on modifiait par programme, sans compter les adresses contenues dans une instruction modifiée par une autre (ha, la joie des switch directement programmés dans le code machine).
On peut toujours le faire dans les architectures modernes, mais, je ne sais pas pourquoi, ce genre de technique a très mauvaise presse (MDR). Sans doute, mais c'est une mauvaise raison, parce que cela rend un programme incompréhensible, particulièrement tordu et totalement illisible, dont la maintenance est impossible que par un autre que celui qui l'a écrit (et encore) ?
[^] # Re: Pour comparer les performances
Posté par abgech . En réponse à la dépêche Kalray un processeur massivement parallèle très impressionnant : Qu’il est loin le temps de mon ZX81. Évalué à 8. Dernière modification le 09 janvier 2014 à 07:52.
Pour prendre un énorme coup de vieux, référence au premier ordinateur qui a vu mes débuts hésitants de programmation : https://en.wikipedia.org/wiki/IBM_1620 .
En Fortran déjà à l'époque ! Puis j'ai appris l'assembler (qui s'appelait le SPS), et je suis tombé dans la marmite à un point tel que, même à la retraite aujourd'hui, je commets encore passablement de lignes en C.
Il y a un groupe de vieux nostalgiques dans mon genre ( à l'époque, l'informatique, c'était le Far West, il fallait tout inventer) qui s'amusent à simuler la 1620 (on disait la et pas le) : http://www.jowsey.com/java/sim1620/.
Je ne sais pas ce qui me retient de me joindre à eux (peut-être java, MDR), parce que, je me souviens encore très bien du SPS et du fonctionnement interne du CPU.
En cours d'exécution du programme, on pouvait, pour débugger, aller, par un bouton hardware, d'instruction en instruction, voire pas à pas à l'intérieur des différents cycles machine (lecture, décodage, exécution) tout en examinant l'état des registres internes. Bref, le pied intégral pour les bidouilleurs.
Et ne parlons pas des codes instructions que l'on modifiait par programme, sans compter les adresses contenues dans une instruction modifiée par une autre (ha, la joie des switch directement programmés dans le code machine).
On peut toujours le faire dans les architectures modernes, mais, je ne sais pas pourquoi, ce genre de technique a très mauvaise presse (MDR). Sans doute, mais c'est une mauvaise raison, parce que cela rend un programme incompréhensible, particulièrement tordu et totalement illisible, dont la maintenance est impossible que par un autre que celui qui l'a écrit (et encore) ?