new, et autre allocation memoire en programmation c++
27 réponses
heinquoi
boujour,
je suis en train de maintéréssé la memoire et son utilisation en
programmation.
en c++ on defini plusieurs types de memoires (d'apres "c++:programmation
sous unix, windows et dos" de jesse Liberty & J. Mark Hord):
l'espace global de nom
l'espace memoire disponible ( ou tas)
les registres
l'espace de code
et la pile.
j'aimerais savoir à quoi ils correspondent au niveau materiel ou os.
pour les registres ... pas de problemes c'est au niveau processeur.
pour l'espace de code ... c'est la ou est le code du programme, sous win32,
entre 4Mo et 2Go ds le code programme.
pour les espaces de noms ...c'est la pile.(mais ou le compilateur difinie la
pile, et qui la gere?).
pour le tas ( alloué avec new), ou le compilateur défini le tas, et y a t il
un lien avec la mémoire paginé ?
Je ne connais pas de cas où ce n'est pas la même pile (ce serait se compliquer la vie pour pas grand chose). Mais le C++ ne l'impose pas. Vu que le 6502 dispose d'une pile processeur de maximum 256 octets, les
Ah. J'ignorais. J'ai fait peu d'assembleur 6502 et en ai peu de souvenirs (j'étais jeune et n'ai fait que des tout petits trucs sur Apple ][).
adresses de retour sont bien empilées sur celle-ci, par contre pour permettre d'avoir des variables locales de taille décente, il y a en plus la gestion d'une pile logicielle par le compilo, qui elle peut faire jusqu'a 64ko.
C'est quoi la limite de mémoire adressable par le 6502 ? Ça doit pas être loin de 64ko, non ? Du coup, si la pile fait 64ko, il ne reste pas beaucoup de place pour le reste, et notamment pour ce qui utilise la pile.
-- Arnaud (Supprimez les geneurs pour me répondre)
Mickael Pointier wrote:
Je ne connais pas de cas où ce n'est pas la même pile (ce serait se
compliquer la vie pour pas grand chose). Mais le C++ ne l'impose pas.
Vu que le 6502 dispose d'une pile processeur de maximum 256 octets, les
Ah. J'ignorais. J'ai fait peu d'assembleur 6502 et en ai peu de
souvenirs (j'étais jeune et n'ai fait que des tout petits trucs sur
Apple ][).
adresses de retour sont bien empilées sur celle-ci, par contre pour
permettre d'avoir des variables locales de taille décente, il y a en plus la
gestion d'une pile logicielle par le compilo, qui elle peut faire jusqu'a
64ko.
C'est quoi la limite de mémoire adressable par le 6502 ? Ça doit pas
être loin de 64ko, non ? Du coup, si la pile fait 64ko, il ne reste pas
beaucoup de place pour le reste, et notamment pour ce qui utilise la pile.
--
Arnaud
(Supprimez les geneurs pour me répondre)
Je ne connais pas de cas où ce n'est pas la même pile (ce serait se compliquer la vie pour pas grand chose). Mais le C++ ne l'impose pas. Vu que le 6502 dispose d'une pile processeur de maximum 256 octets, les
Ah. J'ignorais. J'ai fait peu d'assembleur 6502 et en ai peu de souvenirs (j'étais jeune et n'ai fait que des tout petits trucs sur Apple ][).
adresses de retour sont bien empilées sur celle-ci, par contre pour permettre d'avoir des variables locales de taille décente, il y a en plus la gestion d'une pile logicielle par le compilo, qui elle peut faire jusqu'a 64ko.
C'est quoi la limite de mémoire adressable par le 6502 ? Ça doit pas être loin de 64ko, non ? Du coup, si la pile fait 64ko, il ne reste pas beaucoup de place pour le reste, et notamment pour ce qui utilise la pile.
-- Arnaud (Supprimez les geneurs pour me répondre)
Arnaud Meurgues
heinquoi wrote:
merci Arnaud
De rien.
Par ailleurs, et pendant que j'y pense. Tu dis apprendre le C++ dans "c++:programmation sous unix, windows et dos" de jesse Liberty & J. Mark Hord
Si j'en crois les reviews de l'ACCU, il y a des livres plus recommandables que ceux de Jesse Liberty. Il n'y a pas de review spécifique pour ce livre, mais ce qui est dit sur un autre livre du même auteur (en particulier les deux derniers paragraphes) laisse penser qu'il serait bon de choisir un autre livre, sinon en remplacement, au moins en complément : http://www.accu.org/cgi-bin/accu/rvout.cgi?from u_l&file=t001917a
Pour choisir, je suggère par exemple de piocher dans la liste suivante : http://www.accu.org/bookreviews/public/reviews/0sb/beginner_s_c__.htm#recbook
-- Arnaud (Supprimez les geneurs pour me répondre)
heinquoi wrote:
merci Arnaud
De rien.
Par ailleurs, et pendant que j'y pense. Tu dis apprendre le C++ dans
"c++:programmation sous unix, windows et dos" de jesse Liberty & J.
Mark Hord
Si j'en crois les reviews de l'ACCU, il y a des livres plus
recommandables que ceux de Jesse Liberty. Il n'y a pas de review
spécifique pour ce livre, mais ce qui est dit sur un autre livre du même
auteur (en particulier les deux derniers paragraphes) laisse penser
qu'il serait bon de choisir un autre livre, sinon en remplacement, au
moins en complément :
http://www.accu.org/cgi-bin/accu/rvout.cgi?from
u_l&file=t001917a
Pour choisir, je suggère par exemple de piocher dans la liste suivante :
http://www.accu.org/bookreviews/public/reviews/0sb/beginner_s_c__.htm#recbook
--
Arnaud
(Supprimez les geneurs pour me répondre)
Par ailleurs, et pendant que j'y pense. Tu dis apprendre le C++ dans "c++:programmation sous unix, windows et dos" de jesse Liberty & J. Mark Hord
Si j'en crois les reviews de l'ACCU, il y a des livres plus recommandables que ceux de Jesse Liberty. Il n'y a pas de review spécifique pour ce livre, mais ce qui est dit sur un autre livre du même auteur (en particulier les deux derniers paragraphes) laisse penser qu'il serait bon de choisir un autre livre, sinon en remplacement, au moins en complément : http://www.accu.org/cgi-bin/accu/rvout.cgi?from u_l&file=t001917a
Pour choisir, je suggère par exemple de piocher dans la liste suivante : http://www.accu.org/bookreviews/public/reviews/0sb/beginner_s_c__.htm#recbook
-- Arnaud (Supprimez les geneurs pour me répondre)
heinquoi
"Mickael Pointier" a écrit dans le message de news:cdm022$7at$
Je ne connais pas de cas où ce n'est pas la même pile (ce serait se compliquer la vie pour pas grand chose). Mais le C++ ne l'impose pas.
Je n'ai pas de compilateur C++ sur mon Oric, mais j'ai un compilateur C, et
c'est bien le cas sur celui-ci (et je suppose que ca aurait été le même choix pour un compilateur C++).
c'est une machine de collection ?C'est pas jeune l'oric.
Vu que le 6502 dispose d'une pile processeur de maximum 256 octets, les adresses de retour sont bien empilées sur celle-ci, par contre pour permettre d'avoir des variables locales de taille décente, il y a en plus la
gestion d'une pile logicielle par le compilo, qui elle peut faire jusqu'a 64ko.
Merci pour ton poste qui m'ouvre des horizons diff de ma machine et qui est precis.
Chez moi aussi en fait. Je vient d'aller voir un prog simple debug et sur mon intel PIII, et il semblerais qu'il y ait une pile avec le registre ESP qui pointe sur le haut de la pile.Celle ci sert au passage de paramètre ou a la sauvegarde environnement. A cote de ça j'ai une 2eme pile semble t il, le registre EBP pointe sur le bas d'une pile situé a proximité immédiate de ESP. ailleurs, ESP-EBP est légèrement supérieur au volume de donné de type automatique. Donc 2 piles aussi. Par contre je ne sais pas qu'elle volume max elles peuvent avoir ?
-- Cordialement, Heinquoi
"Mickael Pointier" <mpointier@edengames.moc> a écrit dans le message de
news:cdm022$7at$1@apollon.grec.isp.9tel.net...
Je ne connais pas de cas où ce n'est pas la même pile (ce serait se
compliquer la vie pour pas grand chose). Mais le C++ ne l'impose pas.
Je n'ai pas de compilateur C++ sur mon Oric, mais j'ai un compilateur C,
et
c'est bien le cas sur celui-ci (et je suppose que ca aurait été le même
choix pour un compilateur C++).
c'est une machine de collection ?C'est pas jeune l'oric.
Vu que le 6502 dispose d'une pile processeur de maximum 256 octets, les
adresses de retour sont bien empilées sur celle-ci, par contre pour
permettre d'avoir des variables locales de taille décente, il y a en plus
la
gestion d'une pile logicielle par le compilo, qui elle peut faire jusqu'a
64ko.
Merci pour ton poste qui m'ouvre des horizons diff de ma machine et qui est
precis.
Chez moi aussi en fait. Je vient d'aller voir un prog simple debug et sur
mon intel PIII, et il semblerais qu'il y ait une pile avec le registre ESP
qui pointe sur le haut de la pile.Celle ci sert au passage de paramètre ou a
la sauvegarde environnement. A cote de ça j'ai une 2eme pile semble t il, le
registre EBP pointe sur le bas d'une pile situé a proximité immédiate de
ESP. ailleurs, ESP-EBP est légèrement supérieur au volume de donné de type
automatique.
Donc 2 piles aussi. Par contre je ne sais pas qu'elle volume max elles
peuvent avoir ?
"Mickael Pointier" a écrit dans le message de news:cdm022$7at$
Je ne connais pas de cas où ce n'est pas la même pile (ce serait se compliquer la vie pour pas grand chose). Mais le C++ ne l'impose pas.
Je n'ai pas de compilateur C++ sur mon Oric, mais j'ai un compilateur C, et
c'est bien le cas sur celui-ci (et je suppose que ca aurait été le même choix pour un compilateur C++).
c'est une machine de collection ?C'est pas jeune l'oric.
Vu que le 6502 dispose d'une pile processeur de maximum 256 octets, les adresses de retour sont bien empilées sur celle-ci, par contre pour permettre d'avoir des variables locales de taille décente, il y a en plus la
gestion d'une pile logicielle par le compilo, qui elle peut faire jusqu'a 64ko.
Merci pour ton poste qui m'ouvre des horizons diff de ma machine et qui est precis.
Chez moi aussi en fait. Je vient d'aller voir un prog simple debug et sur mon intel PIII, et il semblerais qu'il y ait une pile avec le registre ESP qui pointe sur le haut de la pile.Celle ci sert au passage de paramètre ou a la sauvegarde environnement. A cote de ça j'ai une 2eme pile semble t il, le registre EBP pointe sur le bas d'une pile situé a proximité immédiate de ESP. ailleurs, ESP-EBP est légèrement supérieur au volume de donné de type automatique. Donc 2 piles aussi. Par contre je ne sais pas qu'elle volume max elles peuvent avoir ?
-- Cordialement, Heinquoi
Jean-Marc Bourguet
"heinquoi" <nospam* writes:
Chez moi aussi en fait. Je vient d'aller voir un prog simple debug et sur mon intel PIII, et il semblerais qu'il y ait une pile avec le registre ESP qui pointe sur le haut de la pile.Celle ci sert au passage de paramètre ou a la sauvegarde environnement. A cote de ça j'ai une 2eme pile semble t il, le registre EBP pointe sur le bas d'une pile situé a proximité immédiate de ESP. ailleurs, ESP-EBP est légèrement supérieur au volume de donné de type automatique. Donc 2 piles aussi. Par contre je ne sais pas qu'elle volume max elles peuvent avoir ?
EBP est le pointeur de frame. Il pointe dans la pile, sur les donnees propres a la fonction, permettant donc d'acceder aux donnes locales avec des deplacements fixes (par rapport a EBP) meme quand ESP varie (il peut varier de maniere inconnue a la compilation, avec des choses comme alloca()). Il peut aussi etre utile pour implementer les exceptions.
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
Chez moi aussi en fait. Je vient d'aller voir un prog simple debug et sur
mon intel PIII, et il semblerais qu'il y ait une pile avec le registre ESP
qui pointe sur le haut de la pile.Celle ci sert au passage de paramètre ou a
la sauvegarde environnement. A cote de ça j'ai une 2eme pile semble t il, le
registre EBP pointe sur le bas d'une pile situé a proximité immédiate de
ESP. ailleurs, ESP-EBP est légèrement supérieur au volume de donné de type
automatique.
Donc 2 piles aussi. Par contre je ne sais pas qu'elle volume max elles
peuvent avoir ?
EBP est le pointeur de frame. Il pointe dans la pile, sur les donnees
propres a la fonction, permettant donc d'acceder aux donnes locales
avec des deplacements fixes (par rapport a EBP) meme quand ESP varie
(il peut varier de maniere inconnue a la compilation, avec des choses
comme alloca()). Il peut aussi etre utile pour implementer les
exceptions.
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
Chez moi aussi en fait. Je vient d'aller voir un prog simple debug et sur mon intel PIII, et il semblerais qu'il y ait une pile avec le registre ESP qui pointe sur le haut de la pile.Celle ci sert au passage de paramètre ou a la sauvegarde environnement. A cote de ça j'ai une 2eme pile semble t il, le registre EBP pointe sur le bas d'une pile situé a proximité immédiate de ESP. ailleurs, ESP-EBP est légèrement supérieur au volume de donné de type automatique. Donc 2 piles aussi. Par contre je ne sais pas qu'elle volume max elles peuvent avoir ?
EBP est le pointeur de frame. Il pointe dans la pile, sur les donnees propres a la fonction, permettant donc d'acceder aux donnes locales avec des deplacements fixes (par rapport a EBP) meme quand ESP varie (il peut varier de maniere inconnue a la compilation, avec des choses comme alloca()). Il peut aussi etre utile pour implementer les exceptions.
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
Loïc Joly
Mickael Pointier wrote:
Je n'ai pas de compilateur C++ sur mon Oric
L'Oric, c'est l'ordinateur rouge et noir que tu portes dans tes bras sur la photo du site de ta boîte ?
-- Loïc
Mickael Pointier wrote:
Je n'ai pas de compilateur C++ sur mon Oric
L'Oric, c'est l'ordinateur rouge et noir que tu portes dans tes bras sur
la photo du site de ta boîte ?
L'Oric, c'est l'ordinateur rouge et noir que tu portes dans tes bras sur la photo du site de ta boîte ?
-- Loïc
Arnaud Debaene
Jean-Marc Bourguet wrote:
"heinquoi" <nospam* writes:
Je n'ai tjrs pas saisi l'interet de passer par new pour l'allocation memoire...
Ca permet de creer des structures dynamiques. De la liste au graphe.
je peux tout aussi bien creer mes données a volonté pdt l'execution du programme dans la pile, c'est meme + simple car j'ai pas à gere la destruction. Et j'ai le sentiment que sur un x86 de type 80686 ou +, avec windows 2K, et avec VC++ ou intel c++, je n'aurait pas plus de limitation d'espace memoire dans la pile que dans le tas.
Je ne sais pas si Windows limite la pile. Dos le faisait, Unix le fait toujours (c'est reglable mais ici, c'est 8M si je ne regle rien).
Pour commencer, il y a une pile par thread, pas par processus. Ensuite, sa tialle maximale est écrite dans l'en-tête du programme (donc fixée au moment de la compilation/édition de liens). La valeur par défaut "typique" est 1MO.
Pour répondre à heinquoi : Sur les x86, la pile physique du processeur (les registres EBP et ESP) est bien la même chose que la "pile" C++, utilisée pour les passages de paramètres de fonctions et le stockage des variables statiques (variables à durée de vie automatique). A chaque changement de contexte d'un thread à l'autre, l'OS sauvegarde (entre autres) les valeurs d'EBP et d'ESP du thread qui termine son "time-slice" et mets à jour ces registres avec les valeurs sauvegardées pour le thread qui prend la main sur le processeur. De cette manière, on "change" logiquement de pile tout en travaillant avec les mêmes registres. C'est un mécanisme qu'on retrouve sur la plupart des couple processeur/OS courants aujourd'hui.
Je n'ai tjrs pas saisi l'interet de passer par new pour l'allocation
memoire...
Ca permet de creer des structures dynamiques. De la liste au graphe.
je peux tout aussi bien creer mes données a volonté pdt l'execution
du programme dans la pile, c'est meme + simple car j'ai pas à gere
la destruction. Et j'ai le sentiment que sur un x86 de type 80686
ou +, avec windows 2K, et avec VC++ ou intel c++, je n'aurait pas
plus de limitation d'espace memoire dans la pile que dans le tas.
Je ne sais pas si Windows limite la pile. Dos le faisait, Unix le
fait toujours (c'est reglable mais ici, c'est 8M si je ne regle rien).
Pour commencer, il y a une pile par thread, pas par processus. Ensuite, sa
tialle maximale est écrite dans l'en-tête du programme (donc fixée au moment
de la compilation/édition de liens). La valeur par défaut "typique" est 1MO.
Pour répondre à heinquoi : Sur les x86, la pile physique du processeur (les
registres EBP et ESP) est bien la même chose que la "pile" C++, utilisée
pour les passages de paramètres de fonctions et le stockage des variables
statiques (variables à durée de vie automatique).
A chaque changement de contexte d'un thread à l'autre, l'OS sauvegarde
(entre autres) les valeurs d'EBP et d'ESP du thread qui termine son
"time-slice" et mets à jour ces registres avec les valeurs sauvegardées pour
le thread qui prend la main sur le processeur. De cette manière, on "change"
logiquement de pile tout en travaillant avec les mêmes registres. C'est un
mécanisme qu'on retrouve sur la plupart des couple processeur/OS courants
aujourd'hui.
Je n'ai tjrs pas saisi l'interet de passer par new pour l'allocation memoire...
Ca permet de creer des structures dynamiques. De la liste au graphe.
je peux tout aussi bien creer mes données a volonté pdt l'execution du programme dans la pile, c'est meme + simple car j'ai pas à gere la destruction. Et j'ai le sentiment que sur un x86 de type 80686 ou +, avec windows 2K, et avec VC++ ou intel c++, je n'aurait pas plus de limitation d'espace memoire dans la pile que dans le tas.
Je ne sais pas si Windows limite la pile. Dos le faisait, Unix le fait toujours (c'est reglable mais ici, c'est 8M si je ne regle rien).
Pour commencer, il y a une pile par thread, pas par processus. Ensuite, sa tialle maximale est écrite dans l'en-tête du programme (donc fixée au moment de la compilation/édition de liens). La valeur par défaut "typique" est 1MO.
Pour répondre à heinquoi : Sur les x86, la pile physique du processeur (les registres EBP et ESP) est bien la même chose que la "pile" C++, utilisée pour les passages de paramètres de fonctions et le stockage des variables statiques (variables à durée de vie automatique). A chaque changement de contexte d'un thread à l'autre, l'OS sauvegarde (entre autres) les valeurs d'EBP et d'ESP du thread qui termine son "time-slice" et mets à jour ces registres avec les valeurs sauvegardées pour le thread qui prend la main sur le processeur. De cette manière, on "change" logiquement de pile tout en travaillant avec les mêmes registres. C'est un mécanisme qu'on retrouve sur la plupart des couple processeur/OS courants aujourd'hui.
Arnaud
Mickael Pointier
Je n'ai pas de compilateur C++ sur mon Oric
L'Oric, c'est l'ordinateur rouge et noir que tu portes dans tes bras sur la photo du site de ta boîte ?
Tout à fait :)
Je n'ai pas de compilateur C++ sur mon Oric
L'Oric, c'est l'ordinateur rouge et noir que tu portes dans tes bras sur
la photo du site de ta boîte ?
L'Oric, c'est l'ordinateur rouge et noir que tu portes dans tes bras sur la photo du site de ta boîte ?
Tout à fait :)
Mickael Pointier
adresses de retour sont bien empilées sur celle-ci, par contre pour permettre d'avoir des variables locales de taille décente, il y a en plus la
gestion d'une pile logicielle par le compilo, qui elle peut faire jusqu'a
64ko.
C'est quoi la limite de mémoire adressable par le 6502 ? Ça doit pas être loin de 64ko, non ? Du coup, si la pile fait 64ko, il ne reste pas beaucoup de place pour le reste, et notamment pour ce qui utilise la pile.
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", 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 de soir que pour réussir à accéder à ca dans un langage évolué c'est cauchemardesque, ca fait ressembler l'adressage 12bits du 8086 à de la grosse rigolade :)
Quand à la pile, elle est située en page 1, donc de $100 à $1ff en mémoire, et le registre de pile "S" est sur 8 bits. Les stack overflow sont rapidement atteints.
Mike
adresses de retour sont bien empilées sur celle-ci, par contre pour
permettre d'avoir des variables locales de taille décente, il y a en
plus la
gestion d'une pile logicielle par le compilo, qui elle peut faire
jusqu'a
64ko.
C'est quoi la limite de mémoire adressable par le 6502 ? Ça doit pas
être loin de 64ko, non ? Du coup, si la pile fait 64ko, il ne reste pas
beaucoup de place pour le reste, et notamment pour ce qui utilise la pile.
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", 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
de soir que pour réussir à accéder à ca dans un langage évolué c'est
cauchemardesque, ca fait ressembler l'adressage 12bits du 8086 à de la
grosse rigolade :)
Quand à la pile, elle est située en page 1, donc de $100 à $1ff en mémoire,
et le registre de pile "S" est sur 8 bits. Les stack overflow sont
rapidement atteints.
adresses de retour sont bien empilées sur celle-ci, par contre pour permettre d'avoir des variables locales de taille décente, il y a en plus la
gestion d'une pile logicielle par le compilo, qui elle peut faire jusqu'a
64ko.
C'est quoi la limite de mémoire adressable par le 6502 ? Ça doit pas être loin de 64ko, non ? Du coup, si la pile fait 64ko, il ne reste pas beaucoup de place pour le reste, et notamment pour ce qui utilise la pile.
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", 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 de soir que pour réussir à accéder à ca dans un langage évolué c'est cauchemardesque, ca fait ressembler l'adressage 12bits du 8086 à de la grosse rigolade :)
Quand à la pile, elle est située en page 1, donc de $100 à $1ff en mémoire, et le registre de pile "S" est sur 8 bits. Les stack overflow sont rapidement atteints.
Mike
Arnaud Meurgues
Loïc Joly wrote:
L'Oric, c'est l'ordinateur rouge et noir que tu portes dans tes bras sur la photo du site de ta boîte ?
Rouge et noir ? Ce n'est pas une Oric 1, alors. C'est le successeur. Que je suis déçu... :)
-- Arnaud (Supprimez les geneurs pour me répondre)
Loïc Joly wrote:
L'Oric, c'est l'ordinateur rouge et noir que tu portes dans tes bras sur
la photo du site de ta boîte ?
Rouge et noir ? Ce n'est pas une Oric 1, alors. C'est le successeur. Que
je suis déçu... :)
--
Arnaud
(Supprimez les geneurs pour me répondre)
L'Oric, c'est l'ordinateur rouge et noir que tu portes dans tes bras sur la photo du site de ta boîte ?
Rouge et noir ? Ce n'est pas une Oric 1, alors. C'est le successeur. Que je suis déçu... :)
-- Arnaud (Supprimez les geneurs pour me répondre)
Arnaud Meurgues
Mickael Pointier wrote:
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 ?
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 ?
de soir 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.
ca fait ressembler l'adressage 12bits du 8086 à de la grosse rigolade :)
J'imagine. Encore que les overlap de segments étaient vraiment une horreur.
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 //.
-- Arnaud (Supprimez les geneurs pour me répondre)
Mickael Pointier wrote:
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 ?
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 ?
de soir 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.
ca fait ressembler l'adressage 12bits du 8086 à de la
grosse rigolade :)
J'imagine. Encore que les overlap de segments étaient vraiment une horreur.
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 //.
--
Arnaud
(Supprimez les geneurs pour me répondre)
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 ?
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 ?
de soir 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.
ca fait ressembler l'adressage 12bits du 8086 à de la grosse rigolade :)
J'imagine. Encore que les overlap de segments étaient vraiment une horreur.
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 //.
-- Arnaud (Supprimez les geneurs pour me répondre)
