sBibi
:C'est la seule méthode raisonnable de gérer le heap. Réimplémenter un heap par dessus celui de AMS, c'est nul.tu peux generaliser ca a pas mal de trucs aussi... reimplementer un memory manager pour les VBO c'est nul... reimplementer un memory manager pour la sys mem en se servant de malloc pour allouer les chunks de base, c'est nul...
Oui, il faut un memory manager par système d'exploitation. Plusieurs memory managers l'un par dessus l'autres, c'est:
1. un hack,
2. très difficile à coder correctement et
3. un gaspillage de taille de code.
t'es con.
Insulte gratuite dont tu aurais très bien pu te passer...
C'est très très inefficace en taille!
tu sais, y a trois types de personnes.. ceux qui preferent les optimisations en taille, ceux qui preferent les optimisations en vitesse, et ceux qui preferent les deux en fonction du contexte.
Réponse totalement à côté de la plaque! Le problème n'est pas que c'est inefficace en taille parce que c'est optimisé en vitesse, mais que c'est inefficace en taille à cause de l'abstraction objet, et à cause des dialogues reprogrammés alors qu'ils sont déjà dans le système d'exploitation.
#ifdef _WIN32
asm {
syntaxe M$
}
depuis quand c'est la syntaxe "M$"? la derniere fois que j'ai regarde c'etait la syntaxe intel,
asm {...}, c'est une syntaxe de compilateur. Et la manière de référencer les variables aussi (noms de variable cités directement contre noms de variables avec constraints). Ça n'a rien à voir avec la syntaxe du code en lui-même.
chose logique quand tu compile sur x86 soit dit en passant...
Pas forcément. Le standard sous Unix a toujours été la syntaxe AT&T, donc GCC l'a reprise. Et les versions récentes de GCC et Binutils te permettent d'utiliser la syntaxe Intel si tu la préfères.
la syntaxe gnu pue.. pour l'asm x86...
Personnellement, je trouve la syntaxe AT&T beaucoup plus claire et plus logique. Elle correspond presque 1 à 1 à la syntaxe d'autres machines (meilleures
) comme le 68k. Et elle n'a pas cette absurdité des opérandes "à l'envers" de la syntaxe Intel.
Il n'y a pas de bonne solution.
ah bon? ah pke quand tu vois pas de bonne solution ca veut dire qu'il y en a pas?
woah kevin!
Non, c'est que le seul mapping raisonnable dans cette situation est un mapping 1:1.
Il marche pourbah non justement
TI, et c'est ça l'essentiel.
Si.
Je ne crois pas pouvoir faire mieux que l’équipe TIGCC. En premier lieu, je n’ai pas leur expérience et en second lieu, je suis plus un programmeur d’application qu’un programmeur système.
tu vois kevin, faudrait que tu prenne exemple sur lui, au moins y se prend pas pour dieu
Moi non plus! Si tu continues sur ce ton, je vais finir par faire comme avec Thibaut et refuser de répondre à tes conneries.
Et pour le dernier paragraphe, il se passe vraiment de commentaires.
sBibi :
ah au fait...
"GTC" (y-en a marre du typosquat, soit dit en passant) n'existe pas, n'a jamais existé et n'existera probablement jamais. Tout ce qui a existé sont quelques bêtas privées que très peu de personnes ont pu voir.
1/ ta deuxieme phrase contredit la premiere
Non. Une bêta privée n'est pas une release, indépendamment du temps que vous (Pollux et ses "complices") gaspillez à déformer la réalité. Et un logiciel qui n'a vu aucune release est un logiciel qui n'existe pas, c'est-à-dire un vaporware.
2/ je te confirme qu'il existe, que plus que "tres peu de personnes" ont pu le voir, et qu'il a l'air fort sympathique ^^
edit: t'aurais du venir a l'open
Les gens qui sont venus à l'"Open", ce sont très peu de personnes! Il faudra vraiment sortir de votre espèce de secte et penser à échelle mondiale. La communauté est beaucoup plus grande que la douzaine de lunatiques qui passent toute leur journée sur yAronet et vont à tous les "Open"s.
) qui contenait un heap un peu particulier : je n'avais besoin d'allouer que des structures de 64 ou 128 octets (mais j'avais besoin de les locker) ; résultat, j'ai pu me contenter d'avoir un bitfield contenant les blocs de 64 octets alloués -> efficacité redoutable niveau allocation et libération, jamais de garbage collection
)
