Comment faire un émulateur hector

Tout sur le pou français

Modérateur : Politburo

Avatar du membre
Fabrice Montupet
Administrateur
Administrateur
Messages : 11083
Enregistré le : 17 mai 2002 11:39
Localisation : Nevers - France

Message par Fabrice Montupet »

Vraiment très interessant! Merci Yves!! :D
destroyedlolo
Fonctionne à 2400 bauds
Fonctionne à 2400 bauds
Messages : 1799
Enregistré le : 03 mai 2003 02:24
Localisation : Nonglard (Annecy)
Contact :

Re: Comment faire un émulateur hector

Message par destroyedlolo »

yvesffr a écrit :Salut!

C'est tout chaud, à l'adresse ci-dessous, je raconte comment je m'y prend pour réaliser un émulateur:


http://hectorvictor.free.fr/index.php?p ... o595YVb1BF
Hehe, tres bon document : j'y ait retrouve pas mal des interrogations que je m'etais pose lorque j'avais fait mon emulateur pour Pocket Sharp et souvent t'utilise des solutions totalement differentes de ce que j'ai fait ce qui est tres interessant (meme si je ne suis pas toujours d'accord avec ce que tu dis, comme le coup du tableau de flags en fonction de la valeur de l'accus)

En tout cas, du tres bon boulo !

Lolo
Amiga, UNIX
Sharp, NetBSD http://destroyedlolo.info/
Apache, PHP 100 % dictionnary free
Vacances, Voyages 1 mispelling by word
Avatar du membre
Stéphane Vanlierde
Fonctionne à 9600 bauds
Fonctionne à 9600 bauds
Messages : 2567
Enregistré le : 09 oct. 2002 16:10
Localisation : Marne la Vallée, Seine & Marne, France
Contact :

Message par Stéphane Vanlierde »

Bravo Yves ! toutes mes ficelles de caleçon !
Bon, ben je n'ai plus qu'à me mettre au boulot !
EN attendant => bookmark !
Avatar du membre
JSB
Fonctionne à 300 bauds
Fonctionne à 300 bauds
Messages : 261
Enregistré le : 05 janv. 2004 19:53
Localisation : Nîmes, un jour par mois - le GOULP le reste du temps...

Message par JSB »

C'est du bon boulot, c'est très didactique et parfaitement clair !

@+++
JSB
Avatar du membre
Carl
Fonctionne à 9600 bauds
Fonctionne à 9600 bauds
Messages : 2542
Enregistré le : 03 janv. 2003 23:47
Localisation : www.dole.org
Contact :

Message par Carl »

Très interressant !
Bravo !
ça dépasse mes compétences (je retourne dans mon labo...:cry: ) mais ça fait rêver...pour faire la même chose sur VéGé ! :roll:
Carl
Avatar du membre
yvesffr
Fonctionne à 2400 bauds
Fonctionne à 2400 bauds
Messages : 2127
Enregistré le : 03 juin 2002 22:07
Localisation : 77
Contact :

Re: Comment faire un émulateur hector

Message par yvesffr »

destroyedlolo a écrit : meme si je ne suis pas toujours d'accord avec ce que tu dis, comme le coup du tableau de flags en fonction de la valeur de l'accus)
Justement, ces opinions m'intéressent pour trois raisons: 1. Je me suis peut-etre trompé, 2. Je me suis peut-être mal exprimé (Romu pourra confirmer que ça m'arrive souvent ;) ) 3. Je n'ai pas vu toute une partie du problème.

Bref, tout ca pour améliorer le document et mes connaissances :)
Passes un coup sur irc #silicium , dans tous les cas je t'envoie un pm :)

Merci :)
Yves
"Je vous aime" (© Pocket 1969)
"et moi je suis la vierge marie" (© Stamba 2009)
"Resistance is futile (if < 1 Ohm)"
"Un velux est un linux portugais"
"j'en vois encore un bout, yves" (© 2010 SbM)
"In minitel we trust" - Silicium
Avatar du membre
coimbrap
Fonctionne à 9600 bauds
Fonctionne à 9600 bauds
Messages : 4090
Enregistré le : 04 juil. 2002 14:42
Localisation : Nantes
Contact :

Message par coimbrap »

OK. Merci Yves. J'ai plus qu'à faire avant la mise en ligne la traduction en anglais.
destroyedlolo
Fonctionne à 2400 bauds
Fonctionne à 2400 bauds
Messages : 1799
Enregistré le : 03 mai 2003 02:24
Localisation : Nonglard (Annecy)
Contact :

Message par destroyedlolo »

Ok, je n'avais pas eu le temp de vraiment m'approfondir hier donc plus de commentaires maintenant.
Avant toute chose, l'emulateur que j'ai fait concerne les pocket sharp donc y'a qq trucs qui sont fait totalement differement (genre la gestion du clavier). De plus, ce ne sont que mes commentaires et c'est evidement que je ne pense pas avoir la science infuse donc tous commentaires / debats et corrections sont les bienvenu :wink:
J'ai aussi rajoute qq infos sur ce que j'ai du faire pour les sharp des fois que ca interesse qq'un :wink:

Au Chap 1 J'ai bien aime la note sur la vitesse : c'est vrais que j'ai completement squizer ce point car mon but etait d'avoir qq chose de fonctionnel sur la machine tres lente que j'utilise au taf (station HP 712@80 Mhz). Et c'est vrais que lorsque j'utilise mon emulateur sur ma station SUN a la maison, les jeux comme ChangerMkII sont presque injouable :twisted:

Au Chap 2, je ne suis pas tous a fait d'accord lorsque tu dis qu'il faut se focalise sur une seule machine. Au debut, je ne m'etais aussi concentre que sur le 1350. Mais au fur et a mesure que mon projet avancait, je me suis dit que c'etait domage car il faudrait tout refaire pour emuler par exemple un 1401 alors que l'archi n'est pas si differente que ca ...
Bref, j'ai decoupe mon code pour separe ce qui est independant au model de ce qui est vraiment specifiques. Emuler une nouvelle machine proche se resume donc qu'a modifier qu'une petite partie.
J'ai donc modifier mon code ce qui nous amene au point suivant.

Chap 4.2 Comme je l'avais dit, la rapidite etait le point primordiale de mon emulation. Et vu la rapidite de ma machine, la moindre perte de temp inutile etait super prejudiciable ... J'ai donc fait des tests sur une machine encore plus lente que ma station !
Ben, je ne suis pas d'accord avec tes conclusions sur le C et le C++. Meme si l'utilisation de classes abstraites amene une legere perte de perf (utilisation de table de fonction pour les methode virtuelles), c'est plus que negligeable. Par contre, ca facilite grandement la programmation.
Dans mon exemple, j'ai une classe de base qui emule le CPU et qui est donc le coeur de l'emulation. Pour emuler un model particulier, je n'ai qu'a deriver cette classe en surchargeant les methodes d'I/O (lecture/ecrite memoire, gestion du clavier, ... ) et zou, ca fonctionne.
(bon, j'ai fait qq teste en emulant un 1401 mais je ne l'ai pas encore mis dans mon archive car je n'ai pas encore eu le temp de traiter correctement le clavier, vu le nombre de touches de la machine).

Evidement, tu peux faire la meme chose en C classique, mais c'est a toi de tous gerer et tu n'as plus les checks que fait automatiquement le C++.

Pour la portabilite (4.1 et 4.3) : Arg, j'ai eu plein de galere avec X, surtout pour la gestion du clavier car chaque vendeurs semble s'amuser a gerer la chose d'une maniere differente de son voisin. Je n'ai pris en compte que Nunux, Solaris et HP-UX et j'ai ete oblige de faire plein de bidouilles :x
Par contre, comme toi, j'ai utiliser Motif car c'est aussi l'aventure de compiler Gtk ou KDE sur HP-UX :wink: Pis bon, c'etait pas si complique que ca meme si je n'y connaissait rien au debut de mon projet.

Chap 5.1 le fameux l'accu. Je ne partage pas ton opinion lorsque tu dis :
Certaines de ces instructions positionnent des flags dans le registre F lorsque elles sont exécutées par exemple le flag de signe ou le flag Zéro lorsque le résultat de l'opération est 0, on pourrait créer une routine qui en fonction du résultat stocké dans A, retourne ou positionne les bon flags, mais ce ne serait pas très optimisé ! Le plus simple est de créer un tableau de la taille du nombre de valeurs que peut prendre le registre A et d'y mettre les flags Zero et Signe correspondants à chaque valeur:
Pourquoi ca ne serait pas optimiser ? Si lorsque tu veux avoir la valeur de Z, tu dois faire

Code : Tout sélectionner

ZSTable[Accus] & Z_FLAG 
ben la c'est pas optimiser car ca implique une addition (ptr_base_tableau + val_Accus) et un test logique.
De mon cote, j'aurait plutot fait qqchose du genre :

Code : Tout sélectionner

inline cpu::setA(unsigned char val){
  Accu = val;
  flags = ((!val) ? Z_FLAG : 0) | ((val & 0x80) ? S_FLAG :0);
}
Si ton compilo est bien optimiser, ca va plus vite (pas besoin de faire le (!val) car cette condition est deja 'teste' lors du Accu = val, et pour le second test, ce n'est qu'un simple test logique. En plus, avec le inline du C++, y'a meme pas de perte de temps du a l'appel de la fonction.

Ce qui me chiffonne aussi, c'est :
:arrow: seul l'accus est capable de modifier ces flags ? (sur les sharp, y'a plein de fonction de test qui n'utilisent pas forcement l'accu),
:arrow: il n'y a pas de Carry (flags qui est mis lorsque tu fais par exemple de 255 +1 -> 0 ou de 0 - 1 -> 255 ?

Pour le switch() geant, j'y avais pense dans un premier temps, mais j'ai preferer faire un tableau de pointeur de fonctions. Dans mon cas, je ne fais pas qu'emuler, je desassemble aussi et donc j'ai une tableau pour l'emulation, un autre pour le dessasemblage et j'ai donc trouve ca plus propre car ces 2 tables sont dans le meme fichier de mon code. Mais bon, le switch() est aussi une option interessante ...

Chap 5.2 comme toi, j'ai utilise 2 fonctions pour lire et ecrire la memoire. Par contre, elle fait partie de ma classe CPU et sont donc redefini pour chacun des models que j'emule, en fonction de leur memory map.

Chap 5.3 Ai ai ai : c'etait la que mon emulation perdait plus de temp. La, il y a 2 solutions :
:arrow: soit tu remet a jour l'ecran en fonction de la memoire video a interval reguilier : c'est ce qu'est fait dans POEM qui est un autre emulateur de pocket. Ben, le bleme, c'est que ca fait perdre un temp pas possible car X n'a rien de leger.
:arrow: soit tu ne met a jour que la partie de l'ecran touche lorsque tu modifie la memoire (je pense c'est ce que tu fais). J'ai meme fait encore mieu : je ne modifie l'ecran que si la nouvelle valeur que je met en memoire est differente de la precedente.
Ben, mine de rien, ca a vachement speeder mon emulation sur mes brouettes.

Chap 5.5 je n'ai pas emuler la lecture sur K7 (c'est aussi un des point bloquant pour l'emulation d'un PC-1401) par manque d'infos sur le format utilise et par manque de temps pour le faire.
De mon cote,
:arrow: soit je charge le programme en memoire avant l'emulation,
:arrow: soit j'utilise la RS-232.
J'ai mis une instruction INVALIDE aux point d'entree des routines qui font SIOGetChar() et SIOPutChar(). Ca redirige l'emulation vers une fonction de mon programme qui lit ou ecrit un caractere depuis un fichier.

Voila, je me suis un peu etendu mais j'espere que ca reste comprehensible :wink:

A+

Lolo
Amiga, UNIX
Sharp, NetBSD http://destroyedlolo.info/
Apache, PHP 100 % dictionnary free
Vacances, Voyages 1 mispelling by word
Avatar du membre
romualdl
Fonctionne à 2400 bauds
Fonctionne à 2400 bauds
Messages : 1986
Enregistré le : 23 mai 2002 15:44
Localisation : Beaumont Sur Oise (95)
Contact :

hehe

Message par romualdl »

SAlut,


Pour la partie video, je sais Yves on en a parlé sur IRC mais je pense qu'il faut vraiment se rapprocher au maximum de la technique d'affichage de la machine d'origine afin d'éviter les problèmes futurs (le problème des borders par exemple). Par problème j'entends tout simplement le gars qui a trouvé une petite astuce en codant pour passer à travers les contraintes hardware, o a reussi a utilisé un truc non prevu... Si l'emulo oric n'avait pas été blindé au niveau de l'émulation (meme s'il reste quelques petits details) jamais certains trucs n'auraient pu etre faisables. Donc je ne dis pas que la communauté hector est aussi nombreuse (ou sera) que la communauté oric mais bon (je sais je suis chiant)...

;)
Modifié en dernier par romualdl le 11 mars 2004 13:30, modifié 1 fois.
<Pocket>la striole en a un et il me le montre quand j'ai envie (irc-25/09/2008)
Avatar du membre
romualdl
Fonctionne à 2400 bauds
Fonctionne à 2400 bauds
Messages : 1986
Enregistré le : 23 mai 2002 15:44
Localisation : Beaumont Sur Oise (95)
Contact :

ofaite

Message par romualdl »

au fait je sais c'est facile à dire...
;)
<Pocket>la striole en a un et il me le montre quand j'ai envie (irc-25/09/2008)
Avatar du membre
coimbrap
Fonctionne à 9600 bauds
Fonctionne à 9600 bauds
Messages : 4090
Enregistré le : 04 juil. 2002 14:42
Localisation : Nantes
Contact :

Message par coimbrap »

Ben j'imagine à faire... parce que déjà comprendre... :lol:
Avatar du membre
yvesffr
Fonctionne à 2400 bauds
Fonctionne à 2400 bauds
Messages : 2127
Enregistré le : 03 juin 2002 22:07
Localisation : 77
Contact :

Re: hehe

Message par yvesffr »

romualdl a écrit :Pour la partie video,
Oui, j'émule bien la partie non visible de l'écran le bitmap affiché est bien distinct de l'espace adresse que voit le z80, donc tous les pixels caché sont bien présents :)
"Je vous aime" (© Pocket 1969)
"et moi je suis la vierge marie" (© Stamba 2009)
"Resistance is futile (if < 1 Ohm)"
"Un velux est un linux portugais"
"j'en vois encore un bout, yves" (© 2010 SbM)
"In minitel we trust" - Silicium
Avatar du membre
yvesffr
Fonctionne à 2400 bauds
Fonctionne à 2400 bauds
Messages : 2127
Enregistré le : 03 juin 2002 22:07
Localisation : 77
Contact :

Message par yvesffr »

destroyedlolo a écrit : Au Chap 2, je ne suis pas tous a fait d'accord lorsque tu dis qu'il faut se focalise sur une seule machine. Au debut, je ne m'etais aussi concentre que sur le 1350. Mais au fur et a mesure que mon projet avancait, je me suis dit que c'etait domage car il faudrait tout refaire pour emuler par exemple un 1401 alors que l'archi n'est pas si differente que ca ...
Bref, j'ai decoupe mon code pour separe ce qui est independant au model de ce qui est vraiment specifiques. Emuler une nouvelle machine proche se resume donc qu'a modifier qu'une petite partie.
J'ai donc modifier mon code ce qui nous amene au point suivant.
J'ai fait l'inverse: essayer de prendre toute la gamme en compte dès le départ. En fait c'est bien et pas bien: bien, car ton code est correctement agencé pour prendre en compte toutes les machines, pas bien car tu te disperses, tu n'arrives pas à te focaliser sur une machine en particulier et tu te retrouves avec des machines pas émulées pas 100% identiques aux originales. Donc c'était surtout pour ça que je marquais cela.
Mais oui pour la premiere raison, c'est bien de le prendre en compte, mais ne focaliser que sur une seule machine à la fois :) (surtout quand tu débutes comme moi et que tu veux tout faire en même temps ;) )
destroyedlolo a écrit : Chap 4.2 Comme je l'avais dit, la rapidite etait le point primordiale de mon emulation. Et vu la rapidite de ma machine, la moindre perte de temp inutile etait super prejudiciable ... J'ai donc fait des tests sur une machine encore plus lente que ma station !
Ben, je ne suis pas d'accord avec tes conclusions sur le C et le C++. Meme si l'utilisation de classes abstraites amene une legere perte de perf (utilisation de table de fonction pour les methode virtuelles), c'est plus que negligeable. Par contre, ca facilite grandement la programmation.
J'avais commencé l'émulateur hector1 en C++ sur AIX (oui pour faire style "je me la pète" je développe d'abord sur AIX ;) ) avec un g++ 2.95 non recompilé. Et en C++ c'est vrai que la programmation en sympa, mais ca se trainait pitoyablement sur un F50 :) une fois tout converti en C, et compilé avec gcc 2.95 ça n'avait plus rien à voir, pourtant le C++ que j'utilisais n'était pas un code super compliqué.

destroyedlolo a écrit : Pour la portabilite (4.1 et 4.3) : Arg, j'ai eu plein de galere avec X, surtout pour la gestion du clavier car chaque vendeurs semble s'amuser a gerer la chose d'une maniere differente de son voisin. Je n'ai pris en compte que Nunux, Solaris et HP-UX et j'ai ete oblige de faire plein de bidouilles :x
Ah curieux ça de mon coté j'ai compilé sur AIX 4.3.3ML11, Solaris 2.8 et Linux Debian v3.0r2 i386 et je n'ai eu aucun souci (et c'est le meme code qui est utilisé pour les 3 O/S).
destroyedlolo a écrit : Chap 5.1 le fameux l'accu. Je ne partage pas ton opinion lorsque tu dis :

Code : Tout sélectionner

ZSTable[Accus] & Z_FLAG 
ben la c'est pas optimiser car ca implique une addition (ptr_base_tableau + val_Accus) et un test logique.
De mon cote, j'aurait plutot fait qqchose du genre :

Code : Tout sélectionner

inline cpu::setA(unsigned char val){
  Accu = val;
  flags = ((!val) ? Z_FLAG : 0) | ((val & 0x80) ? S_FLAG :0);
}
Si ton compilo est bien optimiser, ca va plus vite (pas besoin de faire le (!val) car cette condition est deja 'teste' lors du Accu = val, et pour le second test, ce n'est qu'un simple test logique. En plus, avec le inline du C++, y'a meme pas de perte de temps du a l'appel de la fonction.
C'est vrai, sur ce coup la j'ai pas testé les 2 méthodes :)

destroyedlolo a écrit : :arrow: seul l'accus est capable de modifier ces flags ? (sur les sharp, y'a plein de fonction de test qui n'utilisent pas forcement l'accu),
Non non hérésie ! ;) tu as raison je vais modifier le texte, j'aurais du le mentionner.
destroyedlolo a écrit : :arrow: il n'y a pas de Carry (flags qui est mis lorsque tu fais par exemple de 255 +1 -> 0 ou de 0 - 1 -> 255 ?
Si si, mais j'ai un autre tableau pour les instructions qui n'affectent pas le registre A et/ou qui modifient d'autres flags. mais bon je n'en ai pas parlé pour ne pas surcharger :) Mais je vais rajouter du texte pour dire que ca existe et que ce n'est pas le seul tableau ou chose à faire pour émuler la gestion des flags du CPU.
destroyedlolo a écrit : Pour le switch() geant, j'y avais pense dans un premier temps, mais j'ai preferer faire un tableau de pointeur de fonctions. Dans mon cas, je ne fais pas qu'emuler, je desassemble aussi et donc j'ai une tableau pour l'emulation, un autre pour le dessasemblage et j'ai donc trouve ca plus propre car ces 2 tables sont dans le meme fichier de mon code. Mais bon, le switch() est aussi une option interessante ...
C'est vrai que c'est élégant comme solution :)
destroyedlolo a écrit : Chap 5.2 comme toi, j'ai utilise 2 fonctions pour lire et ecrire la memoire. Par contre, elle fait partie de ma classe CPU et sont donc redefini pour chacun des models que j'emule, en fonction de leur memory map.
Oui :) ! Super facile en C++, cool.
destroyedlolo a écrit : Chap 5.3 Ai ai ai : c'etait la que mon emulation perdait plus de temp. La, il y a 2 solutions :
:arrow: soit tu remet a jour l'ecran en fonction de la memoire video a interval reguilier : c'est ce qu'est fait dans POEM qui est un autre emulateur de pocket. Ben, le bleme, c'est que ca fait perdre un temp pas possible car X n'a rien de leger.
Personnellement je procède comme suit: pour coller au plus près au matériel: tous les 1/freq je regarde si l'écran a été modifié, si oui, je rafraichis.

destroyedlolo a écrit : :arrow: soit tu ne met a jour que la partie de l'ecran touche lorsque tu modifie la memoire (je pense c'est ce que tu fais). J'ai meme fait encore mieu : je ne modifie l'ecran que si la nouvelle valeur que je met en memoire est differente de la precedente.
Ben, mine de rien, ca a vachement speeder mon emulation sur mes brouettes.
Ca c'est carrément cool, je vais rajouter ca dans ma routine :) c'est vrai que ca va booster le tout !!!
destroyedlolo a écrit : Chap 5.5 je n'ai pas emuler la lecture sur K7 (c'est aussi un des point bloquant pour l'emulation d'un PC-1401) par manque d'infos sur le format utilise et par manque de temps pour le faire.
De mon cote,
:arrow: soit je charge le programme en memoire avant l'emulation,
:arrow: soit j'utilise la RS-232.
J'ai mis une instruction INVALIDE aux point d'entree des routines qui font SIOGetChar() et SIOPutChar(). Ca redirige l'emulation vers une fonction de mon programme qui lit ou ecrit un caractere depuis un fichier.
Le lecteur de cassettes et les entrées/sorties en règle générale sur hector son encore plus compliquées que ce que je raconte dans mon document, je ne viens d'ailleurs de complètement comprendre le mécanisme qu'aujourd'hui ! :) Il faut que je mette la page à jour !

destroyedlolo a écrit : Voila, je me suis un peu etendu mais j'espere que ca reste comprehensible :wink:
Impec !!! Merci beaucoup !
:)
Yves
"Je vous aime" (© Pocket 1969)
"et moi je suis la vierge marie" (© Stamba 2009)
"Resistance is futile (if < 1 Ohm)"
"Un velux est un linux portugais"
"j'en vois encore un bout, yves" (© 2010 SbM)
"In minitel we trust" - Silicium
Avatar du membre
yvesffr
Fonctionne à 2400 bauds
Fonctionne à 2400 bauds
Messages : 2127
Enregistré le : 03 juin 2002 22:07
Localisation : 77
Contact :

Message par yvesffr »

destroyedlolo a écrit : Chap 5.1 le fameux l'accu. Je ne partage pas ton opinion lorsque tu dis :

Code:
ZSTable[Accus] & Z_FLAG

ben la c'est pas optimiser car ca implique une addition (ptr_base_tableau + val_Accus) et un test logique.
De mon cote, j'aurait plutot fait qqchose du genre :
Code:

inline cpu::setA(unsigned char val){
Accu = val;
flags = ((!val) ? Z_FLAG : 0) | ((val & 0x80) ? S_FLAG :0);
}


Si ton compilo est bien optimiser, ca va plus vite (pas besoin de faire le (!val) car cette condition est deja 'teste' lors du Accu = val, et pour le second test, ce n'est qu'un simple test logique. En plus, avec le inline du C++, y'a meme pas de perte de temps du a l'appel de la fonction.

Bon ben ca m'intriguait tellement que j'ai essayé:

Deux programmes:

prog1.c: (ta solution)

Code : Tout sélectionner

#define Z_FLAG 0x40
#define S_FLAG 0x80

void main()
{
 int flags;
 int val=4;

 flags = ((!val)?Z_FLAG:0)|((val & 0x80) ? S_FLAG :0);
}

prog2.c (ma solution)

Code : Tout sélectionner

unsigned char ZSTable[256];

void main()
{
 int flags;
 int val=4;

 flags = ZSTable[val];
}
Je les passe tous les 2 à la moulinette avec gcc -O9 -S progX.c
Où X est le numero de fichier.
Gcc est la version 3.2.3 sous linux i386.

C'est marrant car on obtient pour les 2 le code:

Code : Tout sélectionner

       pushl	%ebp
	movl	%esp, %ebp
	subl	$8, %esp
	andl	$-16, %esp
	leave
	ret
Marrant :)
"Je vous aime" (© Pocket 1969)
"et moi je suis la vierge marie" (© Stamba 2009)
"Resistance is futile (if < 1 Ohm)"
"Un velux est un linux portugais"
"j'en vois encore un bout, yves" (© 2010 SbM)
"In minitel we trust" - Silicium
destroyedlolo
Fonctionne à 2400 bauds
Fonctionne à 2400 bauds
Messages : 1799
Enregistré le : 03 mai 2003 02:24
Localisation : Nonglard (Annecy)
Contact :

Message par destroyedlolo »

yvesffr a écrit :J'avais commencé l'émulateur hector1 en C++ sur AIX (oui pour faire style "je me la pète" je développe d'abord sur AIX ;) ) avec un g++ 2.95 non recompilé. Et en C++ c'est vrai que la programmation en sympa, mais ca se trainait pitoyablement sur un F50 :) une fois tout converti en C, et compilé avec gcc 2.95 ça n'avait plus rien à voir, pourtant le C++ que j'utilisais n'était pas un code super compliqué.
Tiens, c'est marrant paske de mon cote, j'ai debute aussi avec GCC 2.95 mais sur mon ancienne station HP 715 (25 Mhz il me semble et beaucoup beaucoup plus lente que ma 712 actuelle). Enfin, c'etait surtout que je m'emerdait comme un rat mort a mon taf :wink:
Hum, c'est peut etre a cause de la programmation : c'est vrais que pousser la vision objet a font fait souvent ramer de chez ramer. En fait mon code est mal programmer dans le sens ou c'est un remix entre du procedurale et de l'Objet : je n'utilise l'objet reelement que ou ca me sert a qq chose (oulala, si mes profs entendaient ca :oops:).
yvesffr a écrit :
destroyedlolo a écrit : Pour la portabilite (4.1 et 4.3) : Arg, j'ai eu plein de galere avec X, surtout pour la gestion du clavier car chaque vendeurs semble s'amuser a gerer la chose d'une maniere differente de son voisin. Je n'ai pris en compte que Nunux, Solaris et HP-UX et j'ai ete oblige de faire plein de bidouilles :x
Ah curieux ça de mon coté j'ai compilé sur AIX 4.3.3ML11, Solaris 2.8 et Linux Debian v3.0r2 i386 et je n'ai eu aucun souci (et c'est le meme code qui est utilisé pour les 3 O/S).
Ben, ca reste portable tant que tu reste sur le clavier classic mais ca part vite live des que tu utilise les touches de fonction ou le pave numerique. Par exemple, pour le pave numerique justement, suivant l'OS les codes de transcodage (code interne -> code ASCII) ne se trouve pas dans la meme table suivant que tu es sous Solaris ou HP-UX.
Bon, ceci dit, c'etait mon premier truc sous X donc je suis loin de maitriser reelement la chose et j'ai peu etre fait n'importe quoi :?
yvesffr a écrit : C'est marrant car on obtient pour les 2 le code:

Code : Tout sélectionner

       pushl   %ebp
   movl   %esp, %ebp
   subl   $8, %esp
   andl   $-16, %esp
   leave
[  ret
Marrant :lol:
Hum, je ne connais pas l'assembleur i386 ... mais je parrirai que l'optimiseur s'est rendu compte que le code ne servait a rien (rien n'utilise 'flags') et ... a donc tous virer.
Ce qui reste ne doit etre que sa soupe pour sauvegarder le contexte.

A+

Lolo
Amiga, UNIX
Sharp, NetBSD http://destroyedlolo.info/
Apache, PHP 100 % dictionnary free
Vacances, Voyages 1 mispelling by word
Répondre

Retourner vers « Victor & Hector »