Le Dimanche 22 Juillet 2001 10:55, vous avez �crit :
> > Dimanche 22 Jul 2001 � 00:47:58, Le Bot Jean-Michel �crivait :
> > ---------------
> > Je suis en train de lire le livre de Linus Torvalds (Il �tait une fois
> > Linux, �ditions OEM). Le p�re de notre OS favori y raconte comment dans
> > la premi�re moiti� des ann�es 80, avec son Commodore Vic-20 puis son
> > Sinclair QL, il programmait en langage assembleur voire m�me en langage
> > machine (alors que C existait d�j�, cf. p. 71) !!!
Il ne faut pas �tre surpris comme �a. Quand on est au niveau "syst�me", il
faut obligatoirement ecrire des fonctions en assembleur, parce que tout ce
que tu as � ta disposition, c'est le langage C. El le langage C ce n'est rien
d'autre qu'un vaste n�ant... tout juste une 20aine de mots clef si ma m�moire
est bonne.
Quand tu fais un simple "printf" , tu appelles une fonctiond de la librairie
stdio qu'il a bien fallu �crire, et qui est propre au syst�me.
De m�me que quand tu d�clares un char[] tu d�clares en fait un tableau bas�
sur le type int (qui n'est pas un entier, mais qui est le "mot machine") seul
et unique type du langage C.
Donc, tu comprendras bien qu'il faut disposer de fonctions �l�mentaires,
lesquelles ne peuvent pas �tre �crites en C ... parce que le langage C ne le
permet pas.
Quand � l'histoire de programmer directement en langage machine, je l'ai
moi-m�me fait. La raison en est simple.
J'avais un TRS-80 dot� de 16Ko (oui kilo-octets) de RAM. Lorsque j'avais
charg� le compilateur assembleur, par manque de RAM je ne pouvais compiler
grosso-modo qu'un code source produisant environ 4Ko de code binaire.
Si mon programme executable devait faire plus de 4Ko, il me fallait donc
trouver une autre solution.
J'ai donc utilis� le d�bugger, outil proche du "debug" du DOS pour ceux qui
connaissent, qui n'occupait qu'1 ou 2 Ko de RAM, je pouvait donc produire un
binaire de plus de 10 Ko & le sauvegarder.
J'�crivais donc mon code assembleur, et je le "compilais" � la main.
Ne soyez pas impressionn�s, je parle d'ASSEMBLEUR pas de MACRO-ASSEMBLEUR
(comme MASM). On �tait donc limit� au jeu d'instruction du CPU, on n'avait
pas de macro-instruction du type IF ...
En fait la seule chose que permettait ce genre d'assembleur �tait de mettre
des noms symboliques en colonne 1, et l'adresse de ces noms �tait r�solue par
le compilateur, ainsi que des vommentaires en colonne 4. Ca donnait des truc
du genre :
LOOP XOR A ; RAZ DE L ACCUMULATEUR
LDIR
CALL MYSUB ; FAIRE LES CALCULS
JP NZ,LOOP ; BOUCLER SI PRECISION PAS ATTEINTE
RET ; FIN DE ROUTINE
MYSUB ADD
.......
Dans cet exemple, on voit que chaque instruction assembleur est effectivement
une des instruction �l�mentaire du CPU Z80, et comme quand on code en
assembleur, on a la liste du jeu d'instruction, et on a pour chaque
instruction son code machine.
Par exemple, JP NZ,LOOP
on a dans la doc "saut si l'accumulateur n'est pas � z�ro".
Code machine : C6LLHH o� HH l'octet de poids fort et LL celui de poids faible
de l'adresse o� aller.
De m�me pour CALL MYSUB on voit dans la doc "CDLLHH"
Alors l�, c'est plus probl�matique, parce qu'il faut compter � la main le
nombre d'octets qu'occupent les instructions suivantes pour savoir � quelle
adresse va ser retrouver le d�but de la routine MYSUB (en l'occurrence ca
fera 4 octets plus loin : 3 pour le CALL (CDLLHH) et un pour le RETurn (C9).
mais mis � part ce petit d�tail de calcul d'adresses � la main, c'est
exactement la m�me chose que de coder en assembleur "pur" (pas
macro-assembleur) ou en langage machine... faut juste faire un peu plus gaffe
aux fautes de frappes ;-)
(note, les valeurs que j'ai donn�es sont compl�tement bidon, je ne me
souviens plus du jeu d'instruction Z80, mis � part C9 pour le RET).
