Compilos

Le 07/08/2015 14:28, Kevin Denis a écrit :

Bonjour,

j'ai juste une question sur l'origine des compilateurs.

Je pense qu'au début, on codait en asm. Puis on a utilisé des langages
de plus haut niveau. Et on a donc eu besoin de compilateur pour
transformer le langage de haut niveau en asm.
Mais le compilo, c'est un programme lui aussi, qui doit être compilé?
J'imagine assez bien que les premiers compilateurs ont été écrits
en assembleur directement.

Mais un jour, il y a bien du avoir une transition en disant: on
abandonne l'assembleur, et on ne fait plus que du haut niveau.
Ca c'est passé comment?

C'est juste par curiosité.

le premier:
<https://fr.wikipedia.org/wiki/A-0_System>

il faut écrire un compilateur dans un sous-ensemble du langage désiré
à la fois en assembleur et dans ce sous-ensemble.
tu compiles le source en langage avec celui en assembleur.
puis encore le source mais avec le resultat de la précédente compilation.
si il n'y a pas de bug les deux programmes générés sont les mêmes.
ensuite tu ajoutes des fonctionnalités au langage directement en langage de haut niveau.

--
http://www.franck-pissotte.fr/ vide grenier: electronique, informatique, 100 livres, 300 revues
http://www.pascaland.org/ compilateurs, sources, liens langage pascal, delphi
http://www.maitre-asimov.fr/ ma collection des oeuvres d'Isaac Asimov

Le 07/08/2015 14:28, Kevin Denis a écrit :

Mais un jour, il y a bien du avoir une transition en disant: on
abandonne l'assembleur, et on ne fait plus que du haut niveau.
Ca c'est passé comment?

C'est compliqué. En effet il y des langage de haut niveau qui ne ne sont
pas trop tout en l'étant quand même. Par exemple Forth est considéré
peur ses adeptes de haut niveau, et pourtant les constructions
élémentaires sont très primitive et parfois bootstrappées en ASM (hexa).
De même avec smalltalk qui est très vieux et pourtant de très haut
niveau aussi.

http://gagne.homedns.org/~tgagne/contrib/EarlyHistoryST.html
http://www.forth.com/resources/evolution/
http://www.c4learn.com/c-programming/c-language-history/

a+

sam.

Ca c'est passé comment?

Avec l'augmentation de la puissance des machines. Etant plutôt en industriel
j'ai connu l'époque ou tu te battais pour gratter un cycle d'horloge.

Maintenant tout dépend de ce que tu appelle compilateur, la aussi j'ai
commencé tout papier, tu écrivais directement le code machine en hexa,
ensuite sont venu des compilateurs machine ou tu écrivait en mnémonique avec
pour les plus évolués une bonne gestion des labels d'adressage (et a la main
c'était sacrement galère car il fallait écrire le programme pour en
connaitre l'occupation mémoire, d'ou une préférence a un 0x28nn (jrz) a un
(0xC3nnnn (jmp) ;>))))

Ensuite sont venus les langages évolués, plus ou moins optimisés et rapides
au niveau exécution mais beaucoup plus au niveau conception. L'autre
avantage de ces langages comme il l'a été abordé dans une autre reonse,
c'est que le même programme fonctionnait sur Z80 ou 6800 sans soucis, le
code était adapté.

Alors pour répondre a ta question, la bascule c'est faite a partir du moment
ou le résultat final était suffisamment bon non pas pour plaire au client
mais pour qu'il ne gueule pas trop. L'argent c'est le nerf de la guerre et
ce qui paie les pizzas aux petits gars dans les bureaux et plus tôt le soft
est écrit moins cela coute. Alors l'abandon de l'écriture en machine s'est
fait progressivement suivant les secteurs d'activité, les besoins en
rapidité et les progrès matériel. Il n'était pas rare de faire du mixte,
toute la gestion administrative du programme en haut niveau, toute les
routines de production en ASM.

Donc de la poule et l'oeuf il y a eu surtout le coq et sa plume (pas
beaucoup de fille informaticiennes a cette époque).

Kevin Denis <kevin@nowhere.invalid> writes:

Bonjour,

j'ai juste une question sur l'origine des compilateurs.

Je pense qu'au début, on codait en asm. Puis on a utilisé des l angages
de plus haut niveau. Et on a donc eu besoin de compilateur pour
transformer le langage de haut niveau en asm.
Mais le compilo, c'est un programme lui aussi, qui doit être compil é?
J'imagine assez bien que les premiers compilateurs ont été à ©crits
en assembleur directement.

Mais un jour, il y a bien du avoir une transition en disant: on
abandonne l'assembleur, et on ne fait plus que du haut niveau.
Ca c'est passé comment?

Il faut noter que les langages machine et assembleurs des machines avant
Intel était beaucoup plus agréable à programmer que l'infà ¢me x86.

Les gens pouvaient facilement écrire et lire les programmes directement
en octal (ou plus tard, en hexadecimal). En plus de ça certaines
machines fonctionnaient plus ou moins directement en base dix! En
utilisant le BCD (voir par exemple le 1401).

Justement, c'est sur 1401 que fut crée en 1957 le premier compilateur, un
compilateur FORTRAN, par l'équipe de Backus (d'où la Backus Naur Form,
la syntaxe pour écrire les grammaires des langages de programmation).

D'abord, une petite description de l'IBM 1401.

La mémoire utilise 8 bits par mot, mais 1 bit est utilisé comme b it de
parité (c'est que les tores de ferite, c'est sensible, est ça peut
flipper facilement). Il y a quatre bits binaire utilisé pour encoder un
chiffre decimal (en BCD), un bit A et un bit B qui combinés avec le
chiffre decimal permet d'encoder un caractère de carte perforée.

Rappelons que les cartes perforée IBM avaient 80 colonnes de 12 rang ées,
10 rangées représentant les chiffres de 0 à 9, et les deux a utres
rangées permettant de faire 3 combinaisons qui, multipliées par l es dix
chiffres permettaient d'encoder 30 caractàres en plus des dix chiffres.

Essayer: http://www.kloth.net/services/cardpunch.php
http://www.kloth.net/services/pcard.php?punch2=0123456789+ABCDEFGHIJKLMNO PQRSTUVWXYZ+.%2C%3A%3B!%3F+%28%29+%3C%3D%3E&code=IBM-029&unk=ignore&cco lor=yellow&t=png

Donc on encodait en mémoire un caractère de carte perforée s ur 6 bits,
un groupe de 2 bits A et B, et un groupe de 4 bits en BCD, plus un bit
de parité, reste un bit, qui était utilisé comme marque de c hamp!

Ce bit était à 0 pour tous les caractères d'un champ sauf le dernier.

Et les instructions du processeurs traitaient non pas des données de
taille fixe, mais un nombre variable de caractères en mémoire, qu i était
déterminé par cette marque de fin de champ. On pouvait ainsi par
exemple, additionner un nombre de 3 chiffres à un total de 5 chiffres en
une seule instruction.

Les instructions étaient donc aussi de taille variable, délimit ées par
cette marque de champ, et pouvant contenir les composantes suivantes:
code opération (un caractère), charactère-d, adresse-I (inst ruction,
pour les sauts), addresse-A et adresse-B (pour les arguments); les
formats d'instruction étant:

1: Op
2: Op d-char
3: Op I-addr
4: Op I-addr d-char
5: Op A-addr B-addr
6: Op A-addr B-addr d-char

Ainsi, pour additionner le champ situé à l'adresse 100 au champ s itué à
l'adresse 200, on utilisait une instruction de code opération "A",
l'instruction, en BINAIRE, était donc perforée sur la carte comme:

A100200

Pour brancher sur une adresse, on utilise l'instruction Branch,
caractère B (format 3):

300: A100200
307: B300
311:

Donc le programme binaire lui-même peut être écrit et lu dir ectement: il
n'y a pas besoin d'assembleur ni de compilateur pour écrire des
programmes!


Enfin, si car:

- seul certains caractères son mnémoniques, et pour se souvenir d e ce
que @ our ! signifie, c'est plus dur.

- travailler avec des adresses absolues devient problématique quand on
veut modifier le programme, insérer ou supprimer des instructions, ou
déplacer des champs en mémoire: il faut recalculer toutes les
adresses!

Heureusement, c'est assez facile d'écrire un "assembleur" qui va
effectuer ce calcul d'adresse somme toute assez simple, en mettant en
correspondance des identificateurs symboliques avec les adresses
déterminées par l'assembleur en comptant les caractères; c'e st le SPS
(Système de Programmation Symbolique), le premier assembleur, avec
lequel il y avait une correspondance univoque entre instruction
symbolique et instruction binaire.

Puis fût développé l'autocodeur, un macro-assembleur.

Je ne sais pas le détail des caractéristique de l'autocodeur, mai s il
faut savoir qu'avec un macro-assembleur, à part du point de vue
syntaxique, on peut définir des macros sophistiquées qui permette nt
d'élever le niveau du language de programmation. Il y a donc tré s peu
de différence significative entre un bon macro assembleur et un langua ge
comme C.

Enfin, le point imporant, c'est que même en travaillant en "binaire", on
pouvait écrire des programmes complets et "sophistiqués", bon, av ec les
limites de ces machines, qui avaient de l'ordre de 2000 caractères de
mémoire. (si on enlève 80 caractères pour le tampon d'entr ée du lecteur
de carte, 80 pour le tampon de sortie du perforateur de carte, et 132
pour le tampo de sortie de l'imprimante, ça ne fait plus déjà   que 1708
caractère restant. Et comme les instructions sont de taille variable,
disons en moyenne de 4 caractères, ça ne fait que 427 instructions
(moins la mémoire que l'on doit utiliser pour les données interne s!).

C'est pourquoi, pour utiliser l'autocodeur, il fallait une configuration
un peu plus poussée, de 4000 caractères de mémoire, 4 lecteu rs de
bandes, et un module CPU comparateur qui était optionnel ;-)

Rappelons que sur la calculette Ti59 de la fin des années 1970, il y
avait 100 registres de mémoire OU 960 pas de programme (une instruction
pouvant prendre 1 ou 2 pas de programmes).


Ce contexte étant établi, il faut réaliser que tandis que ce type de
machine est adapté à la programmation des banques et des entrepri ses où,
finalement, il y a trés peu de calcul (quelques additions) et surtout du
déplacement de donnée et des impressions de listings, pour des
applications plus "scientifique", traduire des formules comme:

d=b²-4ac
x1=(-b+√d)/2a
x2=(-b-√d)/2a

en assembleur devient vite fatiguant (il faut compter au moins une
instruction par opération et par parenthèse, donc une bonne trent aine
d'instructions pour ces trois formules, plus une routine pour calculer
la racine carré…).

D'où l'idée de laisser l'ordinateur traduire les formules, faire un
FORmula TRANslator.

18 mois plus tard, on obtient un joli petit compilateur, en 63 phases :-)
http://ibm-1401.info/1401-FORTRAN-Illustrated.html



Alors, le problème avec ce compilateur, c'est que c'est un programme
gigantesque, comparé aux capacités des ordinateurs de l'époq ue. Les 63
phases étaient 63 programmes qui devaient être chargés à   tour de rôle
dans une mémoire de 8000 caractères, pour effectuer chacun son pe tit
travail sur les instructions du programme en cours de compilation qui
restait en mémoire.

Ça prenait donc beaucoup de temps, même si les phases du compilat eur
étaient lues à partir d'une bande.


Encore, dans les années 1980, j'ai débuté dans une mutuelle, sur un
ordinateur qui fonctionnait comme ça (bon, c'était plus les tores de
ferrites, mais des microprocesseurs qui émulaient le fonctionnement de
ces bons vieux ordinateurs), mais maintenant cet ordinateur était
connecté à une vingtaine de terminaux, et finalement, il n'y avai t pas
beaucoup plus de mémoire disponible pour chaque utilisateur, et mà ªme si
on avait des disques dur, ils étaient plein des données des adh érents.
On avait bien un disque amovible avec un compilateur Cobol (5 phases),
mais on n'avait pas assez de place libre sur les disques ou de mémoire
disponible pour l'utiliser, et donc au final, on écrivait encore la
gestion des adhérents et des remboursement en assembleur!

Mais pour revenir aux compilateurs, quelques années après Fortran et le
1401, IBM développa un ordinateur plus puissant, le 704, puis le 709,
puis le 7090 (compatibles), avec 32 Kmots de mémoire, chaque mot faisa nt
36 bits (ou 6 caractères de 6 bits). C'était un ordinateur con çu pour
le calcul scientifique. Ça allait mieux du point de vue de mémoi re,
avec 32 Kmot on a de quoi voir venir (sauf quand on branchait le modem,
car étant donné la vitesse de transmission, il fallait allouer un tampon
qui utilisait le quart ou la moitié de la mémoire!).

Fortran se portait bien, Neuvel Shaw Simon inventaient la liste chaîn ée,
et on se prenait à écrire les premier programmes d'intelligence
artificielle (on n'avait pas encore inventé ce nom là). Les 36 b its
d'une instruction machine sur 704/709/7090 étaient décodés en
considérant 4 champs: un code opération sur 3 bits, une adresse s ur 15
bits (32 Kmots), un modificateur de code opération sur 3 bits, et un
index décrément d'adresse sur 15 bits. La ruse était d'adre sser les
tableaux et les champs sur leur adresse finale, et d'utiliser des index
négatifs, ce qui facilitait les choses pour une machine scientifique
notament lors du report des retenues. Il y avait des instructions pour
accéder à ces 4 champs dans un registre, ainsi il fut naturel de les
utiliser pour implémenter les chaînons de listes chaîné es de Neuvel,
Shaw et Simon, dans une bibliothèque Fortran nommée FLPL
http://www.informatimago.com/articles/flpl/flpl.html
(Fortran-Compiled List-Processing Language) contenant des fonctions
nommées d'après ces parties de registres:

Contents of Signed Prefix part of Register XCSPRF(J)
Contents of Decrement part of Register XCDRF(J)
Contents of Tag part of Register XCTRF(J)
Contents of Address part of Register XCARF(J)

et une fonction pour assembler un mot machine avec ces quatre champs:

XLWORDF(JSP,JD,JA,JT)

Fortran avait une instruction IF qui était assez rudimentaire et qui
permettait seulement d'effectuer un saut si la condition était remplie.
Donc purement en mode "statement", il n'avait pas de IF ternaire
utilisable dans une expression.

C'est pourquoi, lorsqu'un petit nouveau chercheur qui travaillait sur la
question de l'intelligence articielle, et qui inventa d'ailleurs ce
terme pour nommer cette branche, en écrivant en Fortran des programmes
traitant des listes construites avec cette bibliothèque, trouva qu'il
serait bien plus pratique d'avoir un IF ternaire, ou même pourquoi pas,
une instruction de sélection à multiple tests, comme:

delta<0 -> 0
delta>0 -> 2
sinon -> 1

il demanda aux gars du compilateur Fortran d'ajouter cette instruction
if ternaire ou cette instruction de sélection à choix multiple, m ais
avec un compilateur si complèxe, 63 phases en assembleur!, ce fut une
fin de non-recevoir. De même lorsqu'il suggéra au comité en train
d'inventer Algol, d'ajouter cette instruction conditionnel.

Déçu, il se prit alors les vacances 1958 pour réfléchir sur un nouveau
langage de programmation qui lui permettrait de travailler plus
facilement sur ses problèmes d'intelligence articielle, en particulier
le calcul symbolique de fonctions dérivée, et incorporant cette
instruction conditionnelle multiple et bien sur en utilisant ces listes
NSS si pratique pour ces problème.

Et c'est comme ça que John McCarthy découvrit LISP, et écriv it un memo
qu'il publia en Mars 1959.
http://www.informatimago.com/develop/lisp/com/informatimago/small-cl-pgms/a im-8/aim-8.html

Pendant ce temps là, la Navy avait implémenté un compilateur Algol en
assembleur, et fort de ce succès, ils se mirent à le réà ©crire, en Algol
cette fois-ci.

Bon, le memo de McCarthy est trés particulier, car il défini le l angage
de programmation lisp, en écrivant, en lisp, une fonction qui prend un
programme et qui l'exécute (l'interprète). D'une certaine mani ère,
c'est un interpréteur d'un langage écrit dans ce langage.

Mais aussi, comme McCarthy voulait traiter des fonctions avec son
langage de programmation, une particularité de son langage est qu'il
défini une notation pour les listes symboliques, qui lui permet de
décrire sous forme de donnée un programme. (Et c'est sous cette forme
de donnée, que son programme lisp interpréteur prend le programme à
interpréter).

par exemple, la fonction lisp diff qui prend deux paramètres, y é tant
une expression symbolique, et x un symbole dénotant la variable à dériver, calcule
une expression symbolique de la dérivée de la fonction:

diff=λ[[y;x];
[atom[y]⟶
[y=x]⟶ONE;
1⟶ZERO];
first[y]=PLUS⟶combine[PLUS;
maplist[rest[y];
λ[[z];diff[first[z];x]]]];
first[y]=TIMES⟶combine[PLUS;
maplist[rest[y];
λ[[z];
combine[TIMES;
maplist[rest[y];
λ[[w];[z≠ w⟶first[w];
1⟶di ff[first[w];x]]]]]]]]]

Ainsi, diff[(TIMES,X,(PLUS,X,A),Y),X]

retourne: (PLUS,(TIMES,ONE,(PLUS,X,A),Y),
(TIMES,X,(PLUS,ONE,ZERO),Y),
(TIMES,X,(PLUS,X,A),ZERO)).

d(X*(X+A)*Y)/dX = (1*(X+A)*Y)
+(X*(1+0)*Y)
+(X*(X+A)*0)

(en simplifiant, d(X*(X+A)*Y)/dX = (X+A)*Y + X*Y
d(YX²+AYX)/dX = 2YX+AY

McCarthy avait défini deux notations isomorphes: une pour les
expressions de programmes:

diff[first[w];x]
times[x;plus[X;A];Y]

et une pour les données, les listes symboliques:

((CAROTTES,UN,KG)
(TOMATES,DEUX,KG)
(SEL,UNE,BOITE))

ou en applicant l'isomorphime aux expressions ci-dessus:

(DIFF,(FIRST,W),X)
(TIMES,X,(PLUS,X,A),Y)

ce qui lui avait permit de définir dans son mémo la fonction eval qui
prenait une liste symbolique représentant un programme à interpr éter.

McCarthy avait un étudiant, Steve Russell qui se dit, tiens, cette
fonction eval (qui tient en une page), je pourrais l'implémenter en
assembleur 7090 et faire tourner ainsi de programmes lisp. Ceci surpris
un peu John McCarthy, car il n'avait pas fini de paufiner la syntaxe
pour les programmes lisp, et il ne pensait pas que sa définition qu'il
pensait thérique puisse aboutir à un programme. Mais ce fut fait durant
l'été 1959, et rapidement une implémentation d'un interprà ©teur LISP en
assembleur tourna et fut améliorée (invention du ramasse miette, de la
pile d'exécution, introduction de l'opérateur QUOTE pour distingu er les
données des programmes puisqu'on n'avait alors plus qu'une seule
notation pour les deux, suppression des virgules, introduction des
nombres, etc).

Donc en 1960 on avait un interpréteur LISP implémenté en ass embleur.
Mais alors commença le développement d'un compilateur LISP, impl émenté
en LISP, et tournant sur l'interpréteur LISP implémenté en a ssembleur.
Il fut terminé en 1962. Il faut noter que ce compilateur utilisait un
assembleur écrit en LISP, LAP, et utilisant bien sur aussi des listes
symboliques comme instructions source.

Je ne sais pas si le compilateur lisp était "self-hosting", c'est à  
dire, capable de se compiler lui-même, car à l'époque, il y avait
quelques différences sémantiques assez troublantes entre le code
interprété et le code compilé (les notions de lien dynamique ou lexical
n'étaient pas encore au point, ça prit toute la décade des a nnées 1960
pour aboutir à une conceptualisation fine de ce problème (the fun arg
problem) et sa solution avec scheme). Mais avec le compilateur Algol de
la Navy écrit en Algol, ce compilateur LISP écrit en LISP furent les
premier compilateurs écrit dans le langage qu'il compilaient.


Maintenant, écrire un compilateur comme tout programme, dans un langage
de haut niveau ne pose aucun problème (il n'y a plus de contrainte de
resources, taille mémoire, etc); mais il reste toujours le problè me du
bootstrap: si on écrit un compilateur pour un langage X dans le langage
X, comment fait-on pour le compiler? Et justement, on ne fait pas; soit
un écrit un interpréteur pour le langage X dans un autre langage (de
préférence de haut niveau), soit on procède graduellement, e n écrivant
plusieurs versions successives du langage/compilateur qui soient
compilées par le compilateur précédent:

interpréteur0->compilateur0->compilateur1->compilateur2->compilateurX
le compilateur0 est écrit en langage 0 et compile le language 1
le compilateur1 est écrit en langage 1 et compile le language 2
etc. jusqu'à aboutir à une certaine stabilité.

Malgrès ces difficultés de bootstrap, écrire un compilateur dans le
langage qu'il compile et toujours depuis lors un choix courant, surtout
lorsqu'il s'agit d'un nouveau langage, car s'il s'agit d'un nouveau
langage, par définition, il n'y a pas beaucoup de programmes écri ts dans
ce nouveau langage. Le compilateur sert alors pour se tester lui-même.

Si on compile le source du compilateur v2 avec le compilateur v1 un
obtient un compilateur v2 compilé avec v1. Si maintenant on recompile
le source du compilateur v2 le (compilateur v2 compilé avec v1), on
obtient un compilateur v2 compilé avec v2. En comparant le compilateur
v2 compilé avec v1 avec compilateur v2 compilé avec v2, on và ©rifie si le
source v2 n'a pas régressé par rapport au source v1.

D'un autre côté, ça pose un problème de crédibilit é et de confiance, car
on peut introduire une fonction malveillante dans un compilateur, qui
détecte lorsqu'on compile une fonction particulière du compilateu r, et
qui au lieu de générer le code normal de la fonction du nouveau, va copier
code de la fonctin malveillante, et donc ainsi se reproduire de façon
sournoise et cachée, de compilateur en compilateur. De la même f açon
cette fonction malveillante peut détecter si on est en train de compil er
une fonction critique dans le système d'exploitation (comme par exempl e,
la validation des mots de passe), et insérer une porte arrière. C'est
exactement ce qu'avait fait Thompson dans un des premiers compilateur C
sur le système unix! :-)

Par contre, si le langage X est implémenté par un compilateur à ©crit dans
le langage Y, c'est un peu plus difficile d'introduire une telle
fonction, surtout si le langage X n'est pas connu lorsqu'on a compilé le
compilateur du langage Y.


https://www.ece.cmu.edu/~ganger/712.fall02/papers/p761-thompson.pdf
https://www.schneier.com/blog/archives/2006/01/countering_trus.html
https://en.wikipedia.org/wiki/History_of_compiler_construction
http://www.softwarepreservation.org/projects/

--
__Pascal Bourguignon__

Je ne sais pas si le compilateur lisp était "self-hosting", c'est à
dire, capable de se compiler lui-même, car à l'époque, il y avait
quelques différences sémantiques assez troublantes entre le code
interprété et le code compilé (les notions de lien dynamique ou lexical
n'étaient pas encore au point, ça prit toute la décade des années 1960
pour aboutir à une conceptualisation fine de ce problème (the funarg
problem) et sa solution avec scheme). Mais avec le compilateur Algol de
la Navy écrit en Algol, ce compilateur LISP écrit en LISP furent les
premier compilateurs écrit dans le langage qu'il compilaient.

Addendum:

http://www.softwarepreservation.org/projects/LISP/lisp1.5/LISP_LIBRARY_NOVEMBER_1963.pdf

indique que le compilateur LISP était effectivement capable de se
compiler lui-même, en étant interprété par l'interpréteur LISP.

"It is written entirely in LISP and is the first compiler that has ever
compiled itself by being executed interpretively."

Peut être que le compilateur Algol de la Navy était compilé avec un
autre compilateur Algol, et ne se compilait pas lui-même?


--
__Pascal Bourguignon__

[..]

Très intéressant, merci de ce long texte sur l'histoire des compilateurs!

Guillaume.

Le 08/08/2015 16:53, Pascal J. Bourguignon a écrit :

Contents of Decrement part of Register X _CDR_ F(J)
Contents of Address part of Register X _CAR_ F(J)

D'où les fameuses instructions "car" et "cdr" pour ceux qui ont fait le
lisp. (https://en.wikipedia.org/wiki/CAR_and_CDR)

Merci pour ce (long) résumé des compilateurs. Ca ne nous rajeunit pas.

a+

sam.

Le 8 août 2015 à 16:53, Pascal J. Bourguignon a dit :

[ un post de qualité encyclopédique ]

Merci Pascal pour toutes ces infos sur les premiers compilos et la
génèse de LISP !

--
Sébastien Kirche - envoyé depuis un programme LISP ;o)

Le 08/08/15 01:18, Pascal-J a écrit :

c'était sacrement galère car il fallait écrire le programme pour en
connaitre l'occupation mémoire, d'ou une préférence a un 0x28nn (jrz) a un
(0xC3nnnn (jmp) ;>))))

C'est bo comme du Z80 ;-)