new, et autre allocation memoire en programmation c++

Oui, exactement 64ko, mais la majorité des systèmes à base de 6502 et
dérivés ont une partie de la mémoire qui est "paginée",

Heu... La majorité ? Tu veux dire les trucs modernes ou c'était déjà
vrai dans les années 80s ?

Toutes les machines à base de 6502 qui ont plus de 64ko de mémoire :)

Par exemple le Commodore 128 et l'Oric Telestrat, qui ont une logique de
sélection de banque.

en passant par de la
logique de controle on peut faire en sorte que par exemple les 16ko ou
32ko

supérieurs soient en fait une fenêtre dans une grosse zone de mémoire.
Il va

Certes. Mais pour faire une pile de 64ko, c'est pas le pied. C'est ce
que fait l'Oric ?

Elle ne fait pas 64ko, elle fait la taille que le programmeur veut, dans la
limite de ce qu'il reste comme mémoire. Donc je peux très bien avoir un
exécutable de 3ko avec une pile de 15ko si je veux (par exemple pour faire
des calculs récursifs avec une profondeur relativement poussée, style
calculer un ensemble de mandelbrot).

de soit que pour réussir à accéder à ca dans un langage évolué c'est
cauchemardesque,

Ah ? Un langage évolué ne peut pas le rendre transparent. J'aurais
plutôt eu tendance à dire que c'est en assembleur que c'est
cauchemardesque.

Disons que le problème c'est que l'architecture mémoire est comme ca, et
l'OS ne propose rien de spécial pour y accéder, en gros tu tappes dans les
ports d'entrées/sorties pour sélectionner la banque, et tadaaaa, les données
sont disponibles.

Les compilateurs qui ont été développés depuis sont particulièrement
difficile à adapter, et faire en sorte qu'il puisse générer un code
"saucissoné" en multiples banques, et de se débrouiller pour qu'il sache à
un moment donné qu'on est dans la banque "machin" et que donc si je veux
appeller la fonction "truc" il faut basculer sur la banque "schmurtz" (me
privant donc du même coup de l'accès de tout ce qui se trouvait dans
"machin", c'est à dire code et données). C'est loin d'être trivial vu qu'il
faut retrier les données et fonctions qui sont communes à plusieurs modules
pour les mettre dans une partie commune. Ensuite il faut optimiser les
changement de banque, sinon au niveau performance c'est catastrophique et ca
génère du code inutile qui fait grossir le programme et donc rend nécéssaire
le fait d'avoir des banques :)

ca fait ressembler l'adressage 12bits du 8086 à de la
grosse rigolade :)

J'imagine. Encore que les overlap de segments étaient vraiment une
horreur.

Les comparaisons de pointeurs aussi !
Deux pointeurs différents pouvant indiquer la même adresse physique, ca
donne des résultats amusant en mode réel.

Quand à la pile, elle est située en page 1, donc de $100 à $1ff en
mémoire,

Ça doit faire un sacré paquet d'années que je n'avais pas vu des nombres
hexa écrits avec un $. Merci pour l'épisode nostalgie. J'en regrette
presque de m'être séparé de mon Apple //.

Je n'ai jamais pu supporter les &h et autre 0x

Mike (qui aimerait bien avoir un compilateur C++ sur son oric pour le
fun)

Mickael Pointier wrote:

Heu... La majorité ? Tu veux dire les trucs modernes ou c'était déjà
vrai dans les années 80s ?
Toutes les machines à base de 6502 qui ont plus de 64ko de mémoire :)

Gnagnagna. :)

Par exemple le Commodore 128 et l'Oric Telestrat, qui ont une logique de
sélection de banque.

Ok.

Elle ne fait pas 64ko, elle fait la taille que le programmeur veut, dans la

Oui, oui. C'était juste pour plaisanter. C'est toi qui a dit que la pile
pouvait faire 64ko. :)

Les compilateurs qui ont été développés depuis sont particulièrement
difficile à adapter, et faire en sorte qu'il puisse générer un code
"saucissoné" en multiples banques, et de se débrouiller pour qu'il sache à
un moment donné qu'on est dans la banque "machin" et que donc si je veux
appeller la fonction "truc" il faut basculer sur la banque "schmurtz" (me
privant donc du même coup de l'accès de tout ce qui se trouvait dans
"machin", c'est à dire code et données). C'est loin d'être trivial vu qu'il
faut retrier les données et fonctions qui sont communes à plusieurs modules
pour les mettre dans une partie commune.

Tu peux peut-être t'en servir pour faire du multitasking efficace,
remarque. Une tâche par banque...

Les comparaisons de pointeurs aussi !
Deux pointeurs différents pouvant indiquer la même adresse physique, ca
donne des résultats amusant en mode réel.

Oui, quel bonheur ! Comment un tel processeur a-t-il pu avoir du succès ?!

Mike (qui aimerait bien avoir un compilateur C++ sur son oric pour le
fun)

J'imagine bien un compilo C++ à la norme en 64ko, tiens... :-)

--
Arnaud
(Supprimez les geneurs pour me répondre)

Arnaud Meurgues <arnaud@meurgues.non.fr.invalid> writes:

J'imagine bien un compilo C++ à la norme en 64ko, tiens... :-)

Les techniques pour le faire sont connues. Multiple passes avec
executables separes, overlay et gestion des donnees sur disque avec
fichiers temporaires. Si c'est une contrainte connue des le depart,
c'est pas beaucoup plus difficile a faire qu'en compilo C++ a la
norme, sinon il vaut vraissemblablement mieux repartir du depart si on
veut la moindre efficacite. La difficulte supplementaire principale
serait vraissemblablement de trouver les gens maitrisant les
techniques ci-dessus.

A+

--
Jean-Marc
FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ
C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html
Site de usenet-fr: http://www.usenet-fr.news.eu.org

Jean-Marc Bourguet wrote:

J'imagine bien un compilo C++ à la norme en 64ko, tiens... :-)
Les techniques pour le faire sont connues. Multiple passes avec

executables separes, overlay et gestion des donnees sur disque avec
fichiers temporaires.

Sur cassette, s'il te plait. On parle d'Oric, là. ;-)
Je sens que la compilation serait une partie de plaisir à faire
regretter les batches et les cartes perforées.

veut la moindre efficacite. La difficulte supplementaire principale
serait vraissemblablement de trouver les gens maitrisant les
techniques ci-dessus.

Et la motivation pour le faire.

--
Arnaud
(Supprimez les geneurs pour me répondre)

J'imagine bien un compilo C++ à la norme en 64ko, tiens... :-)
Les techniques pour le faire sont connues. Multiple passes avec

executables separes, overlay et gestion des donnees sur disque avec
fichiers temporaires.

Sur cassette, s'il te plait. On parle d'Oric, là. ;-)
Je sens que la compilation serait une partie de plaisir à faire
regretter les batches et les cartes perforées.

Rha l'autre...
Déja, j'ai 2 lecteurs de disque, un 3" et un 3.5" (je peut en mettre deux
autres en plus), donc il est parfaitement possible d'avoir le compilateur et
le système sur un disque, le code source à compiler sur un autre, les
temporaires sur un troisième et le résultat de la compilation sur le dernier
:)

Sérieusement, je travaille en compilation croisée. L'intérêt de faire ca en
natif est extremement limité. Même à l'époque la majorité des jeux et
applications n'étaient pas écrites sur les machines cibles mais sur des
machines disposant de plus de mémoire et de processeurs plus rapide.

Générer du code potable pour un processeur avec 3 registres 8bits
spécialisés est déja suffisament complexe pour ne pas en plus se prendre la
tête avec le fait de faire tenir le code du compilateur dans une mémoire
limité :)

D'ailleur, lorsque je regarde la façon dont je code en assembleur, et ce que
devrait faire un compilateur C/C++ pour être efficace, je me demande si
certaines optimisations sont faisables tout en respectant la norme.

Par exemple, le stockage des données, qu'est-ce qui est imposé au juste ?

Imaginons que j'ai un table de 5 valeurs 16 bits (des shorts ici). En C(++)
ca donnerais ca:

short gMyTable[5];

ensuite, sur le tableau on peut faire un certain nombre d'opérations:

gMyTable[1]345;
short a=gMyTable[4];
short *p_table=&gMyTable[2];

le problème, c'est qu'en assembleur sur un 6502, jamais on ne stocke une
table de valeurs 16 bits de cette façon, parce que c'est totalement
inneficace sur ce processeur 8 bits. La manière dont on le fait, c'est comme
ca:

char gMyTable_low[5];
char gMyTable_high[5];

gMyTable_low[1]=(12345&255);
gMyTable_high[1]=(12345>>8);
short a=((short)gMyTable_low[4])+(((short)gMyTable_high[4])<<8);

le problème étant évidemet ce genre de truc:

short *p_table=&gMyTable[2];

comment faire pour manipuler le pointeur si on ne connait pas la taille de
la table ?

Donc à cause des données dont on ne connais pas la taille lors de la
compilation, le compilateur, ne peux pas à priori optimiser ce genre de
code, ce qui est dommage parce qu'au niveau performance c'est pas loin de
deux fois plus rapide tout en prenant deux fois moins de place au niveau
taille de code (ce qui entraine d'autres optimisations vu que du coup on
peut utiliser les branchements courts au lieu des branchements longs).

En ayant une valeur 16 bits, le code généré pour lire la valeur ressemble à
ca:

.zero

index .dsb 1
value .dsw 1

.data

gMyTable .dsw 5

.text

lda index
lsl
tay
lda gMyTable,y
sta value+0
iny
lda gMyTable,y
sta value+1

Alors qu'avec deux tables de valeurs 8 bits, ca donnerait ca:

.zero

index .dsb 1
value .dsw 1

.data

gMyTable_low .dsb 5
gMyTable_high .dsb 5

.text

ldy index
lda gMyTable_low,y
sta value+0
lda gMyTable_high,y
sta value+1

donc vala, je sais pas si y'a moyen de respecter la norme tout en
réussissant à être efficace sur ce genre de choses ?

veut la moindre efficacite. La difficulte supplementaire principale
serait vraissemblablement de trouver les gens maitrisant les
techniques ci-dessus.

Et la motivation pour le faire.

Effectivement :)

Mike (qui est en vacances ce soir pour un mois et ne va donc pas suivre
le reste du thread)

"Mickael Pointier" <mpointier@edengames.moc> writes:

Sérieusement, je travaille en compilation croisée.

Ca n'a guere de sens de faire autre chose de nos jours. Mais les
techniques que j'ai evoquees ont ete utilisees pour des compilateurs.

[...]

donc vala, je sais pas si y'a moyen de respecter la norme tout en
réussissant à être efficace sur ce genre de choses ?

Il y a toujours la regle du comme-ci. Tant que le programme ne voit
pas la difference avec ce qui est requis par la norme tout est permis
et le compilateur peut eviter de faire ca si le programme fait quelque
chose qui lui permettrait de detecter la difference..

Si j'ai bonne memoire, le compilateur C de Sun est capable de faire
quelque chose d'approchant: changer un tableau de structure en une
structure de tableau (cherchons un peu, ... google, ..., je crois que
Oaox9.1780$mP3.103447683@newssvr13.news.prodigy.com est dans la
discussion a laquelle je pense, il y a meme l'air que le tableau est
alloue avec malloc !). La transformation que tu proposes est
suffisemment proche pour qu'elles soit tout autant du domaine du
possible.

A+

--
Jean-Marc
FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ
C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html
Site de usenet-fr: http://www.usenet-fr.news.eu.org

"Arnaud Meurgues" <arnaud@meurgues.non.fr.invalid> a écrit dans le message
news: 4100c06c$0$1512$636a15ce@news.free.fr...

Jean-Marc Bourguet wrote:

J'imagine bien un compilo C++ à la norme en 64ko, tiens... :-)
Les techniques pour le faire sont connues. Multiple passes avec

executables separes, overlay et gestion des donnees sur disque avec
fichiers temporaires.

Sur cassette, s'il te plait. On parle d'Oric, là. ;-)
Je sens que la compilation serait une partie de plaisir à faire
regretter les batches et les cartes perforées.

J'ai compilé du Fortran avec sorties intermédiaires entre 2 passes
sur... ruban perforé !! Je t'assure que tu faisais gaffe à la syntaxe,
faute de quoi la pièce ressemblait rapidement à une salle de bal
un 1er janvier à 0h10 ;-)

--

Français *==> "Musique renaissance" <==* English
midi - facsimiles - ligatures - mensuration
http://anaigeon.free.fr | http://www.medieval.org/emfaq/anaigeon/
Alain Naigeon - anaigeon@free.fr - Strasbourg, France