Moka - Page 2

Hippohmu
:

Pollux
: Je pense qd même qu'une partie très significative du heap a été reprogrammée...

#ter# : Ce n'est pas un Heap !!!
Et certes, une partie est reprogrammée, mais ça n'empêche pas que le code arm natif doit se conformer aux structures de données du saturn : champs de 20 bits, adresses en quartets et indifféremment paires ou impaires.

Oui, d'accord pour les structures de données.

Si tu veux faire un heap "comme en C", ces routines-là sont utilisables (quitte à remplacer free() par un nop) mais pas efficaces.

(still a bit confused) C'est lesquelles, "ces routines là"?

Ben je sais pas, y a bien une routine pour allouer de la mémoire, non?

On ne peut pas faire de Heap "à la C" à partir des routines mémoires de la rom. (en première approximation, du moins).

Si mon malloc(12345) consiste à créer un objet Code de 12345 octets et à le rajouter à la liste AllocatedBlocks, et que mon free() consiste à supprimer cet objet de la liste, j'ai bien fait un heap "à la C", non? Et ça fait bien 16000 allocations par seconde, pour des tailles faibles?

#si#

D'ému ou de SDK ?

Emu.
Et Jean Yves Avenard semblait intéressé sur comp.sys.hp48, ce qui laisse à croire que Hp n'a pas fait d'ému pour eux.

Les flemmards ^^ "si vous voulez programmer en RPL, vous pouvez utiliser l'ému 49g"

Pollux :
Ben je sais pas, y a bien une routine pour allouer de la mémoire, non?

Si mon malloc(12345) consiste à créer un objet Code de 12345 octets et à le rajouter à la liste AllocatedBlocks, et que mon free() consiste à supprimer cet objet de la liste, j'ai bien fait un heap "à la C", non? Et ça fait bien 16000 allocations par seconde, pour des tailles faibles?

On n'a pas de garantie qu'un objet alloué restera à une adresse fixe. (et en pratique, il ne reste effectivement pas à adresse fixe). Voilà pourquoi il n'y a pas de simulation d'un "Heap à la C" possible!

d'autre part, il n'y a pas de free(). On ne libère qu'avec un GC.

#si#

#si#

Hippohmu
:

Pollux :
Ben je sais pas, y a bien une routine pour allouer de la mémoire, non?

Si mon malloc(12345) consiste à créer un objet Code de 12345 octets et à le rajouter à la liste AllocatedBlocks, et que mon free() consiste à supprimer cet objet de la liste, j'ai bien fait un heap "à la C", non? Et ça fait bien 16000 allocations par seconde, pour des tailles faibles?

On n'a pas de garantie qu'un objet alloué restera à une adresse fixe. (et en pratique, il ne reste effectivement pas à adresse fixe). Voilà pourquoi il n'y a pas de simulation d'un "Heap à la C" possible!

OK, d'accord. C'est pareil pour le heap privé de GT-Basic. Mais c'est dommage, pour le heap global... Ca prive la 49G+ de toute une énorme bibliothèque de progs.

d'autre part, il n'y a pas de free(). On ne libère qu'avec un GC.

Oui, c'est ce que je disais plus haut.

#si#

#si#

(bon, il faudrait arrêter de flooder le topic Quesoft va être horrifié )

retour au sujet plz

Stop le flood

cross d'accord avec toi, Ximoon

vince
: A tu prévu des interfaces avec GTC ? (gtc est le compilateur C oncalc de Pollux)

Non, pour l'instant le seul compilateur supporté est TIGCC.

La prochaine mise à jour sera moins dépendante du compilateur C. On pourra développer un API pour un compilateur en particulier en modifiant simplement quelques fichiers de configuration (et en se tappant la programmation de l'API).

D'ailleurs, la prochaine version devrait offrir un api ANSI qui pourra être compilé sous GCC et VC++.

Pollux :
Quesoft> Comment Moka se débrouille-t-il sans garbage collection ? Le prog s'arrête violemment quand il est à court de mémoire ? Le programmeur est censé libérer la mémoire ? Il y a le gros garbage-collector qui se met en marche et freeze la calc pendant 2 secondes ? (comme sur HP )

A propos du tas, est-ce que :
- tu alloues avec HeapAlloc/HeapFree ou tu as fais des fonctions plus efficaces ? (ce serait vraiment dommage d'utiliser les fonctions horriblement lentes du TIOS)
- ton compilo est capable d'optimiser lorsqu'il constate qu'une variable n'est pas accessible aux fonctions appelantes, pour éviter l'allocation sur le tas et passer par la pile ? (pour faire un peu comme en C++ )

Est-ce qu'il y a des switch pour activer le contrôle de débordement des entiers comme en Java ? (puisque je présume que c pas activé par défaut)

Enfin, est-ce qu'il y a des optimisations globales du genre ajout de "final" si la définition de la fonction n'est pas overridée par des sous-classes ?

Enfin bon, j'ai pas eu le temps de regarder ça de plus près, mais si c pas trop inefficace, ça a l'air prometteur


geogeo> lol, la pub à peine déguisée ^^
vince> ça m'a pas l'air évident à première vue, il faut déjà que le compilo Moka soit prévu pour être léger (au niveau ROM _et_ au niveau RAM), et ensuite il faut que la bibliothèque de classes tienne dans la calc (et ça, c vraiment pas gagné a priori). Peut-être que ce serait possible avec une modif de la bibliothèque de classes ?

Il n'y a pas de garbage collector. En fait il y en a un très inéfficasse qui se contente - s'il est activé - de finaliser les objets avant que le programme se termine. Pas très pratique. En temps normal, on doit manuellement finaliser les objets que l'on veut détruire. ex :
obj.finalize()

J'alloue avec l'alias malloc de HeapAlloc. Comme je suis pas skillé en assembleur 68000 (en fait le seul assembleur que je connais est celui de la z architecture !), je ne vois pas une autre façon d'implémenter cette fonction.
Le compilateur n'alloue pas d'objet sur la pile, désolé

Il n'y a pas de contrôle de débordement d'entiers ou de tableaux. Moka a été conçus pour être le plus rapide possible et ces contrôles, auraient été lourds.

Si une méthode n'est pas overridée par une sous classe, la sous classe ne référencera pas une copie, mais bien la même fonction que ça superclasse pour des fins d'optimisation

Moka a été conçus pour être léger (d'où les limitations), mais il n'y a pas de bibliothèque de classes à copier sur la calc. Moka produit des asm s'emblable tout programme C.

Quesoft :
Il n'y a pas de garbage collector. En fait il y en a un très inéfficasse qui se contente - s'il est activé - de finaliser les objets avant que le programme se termine. Pas très pratique. En temps normal, on doit manuellement finaliser les objets que l'on veut détruire. ex : obj.finalize()

D'accord... C'est dommage, parce que ça doit être un peu galère pour gérer à la main la libération des chaînes de caractères

J'alloue avec l'alias malloc de HeapAlloc. Comme je suis pas skillé en assembleur 68000 (en fait le seul assembleur que je connais est celui de la z architecture !), je ne vois pas une autre façon d'implémenter cette fonction.

Pas besoin de le faire en assembleur, du C suffirait Mais c vrai que c un peu long à faire...

Il n'y a pas de contrôle de débordement d'entiers ou de tableaux. Moka a été conçus pour être le plus rapide possible et ces contrôles, auraient été lourds.

OK.

Si une méthode n'est pas overridée par une sous classe, la sous classe ne référencera pas une copie, mais bien la même fonction que ça superclasse pour des fins d'optimisation

Oui j'imagine bien, mais si tu as :

class A {
f() { ... }
};

et qu'aucune autre classe ne dérive de A, tu peux enlever f de la table de fonctions virtuelles, non?

Moka a été conçus pour être léger (d'où les limitations), mais il n'y a pas de bibliothèque de classes à copier sur la calc. Moka produit des asm s'emblable tout programme C.

Euh, vince parlait de mettre le compilateur Moka lui-même sur calc, pour pouvoir l'utiliser avec un compilateur C directement sur la calc

Pollux :
D'accord... C'est dommage, parce que ça doit être un peu galère pour gérer à la main la libération des chaînes de caractères

L'API est conçus pour palier au problème. La plupart des méthodes qui acceptent des instances de String se les approprient. Ex:
String toto = "debut"; //Instancie une String

toto += "fin"; //L'objet toto s'approprie la string instanciée avec "fin" et la finalise ultimement

Si on veut conserver l'objet, on passe une copie :

toto += toto.tostring();//toString, dans le cas d'une String retourne une copie de la String

Pollux :
Euh, vince parlait de mettre le compilateur Moka lui-même sur calc, pour pouvoir l'utiliser avec un compilateur C directement sur la calc

ok, je vois

Pollux :
Oui j'imagine bien, mais si tu as :

class A {
f() { ... }
};

et qu'aucune autre classe ne dérive de A, tu peux enlever f de la table de fonctions virtuelles, non?

Je vois, mais Moka ne fais pas ce genre d'optimization - pour l'instant. Dailleurs, en Java, toutes les méthodes (non statiques) sont virtuelles.

La prochaine mise à jour portera principalement sur deux points:

- Support de multiples compilateurs.

- Révision de l'optimisation : De nouvelles optimisations seront ajoutées. De plus, j'ai remarqué des lacunes qui, sans nuire à la rapidité ou à la stabilité des programmes compilés, font que le compilateur inclue du code marqué inutilisé.

vince
: A tu prévu des interfaces avec GTC ? (gtc est le compilateur C oncalc de Pollux)

Raaah, comme d'habitude, dès qu'on parle de compilateurs: blabla blabla GTC blabla blabla Pollux blabla blabla...
"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.
Et je ne vois pas pourquoi il devrait perdre son temps pour supporter ce compilateur en tant que backend alors qu'il y a TIGCC qui marche très bien.

Pollux :
A propos du tas, est-ce que : - tu alloues avec HeapAlloc/HeapFree ou tu as fais des fonctions plus efficaces ? (ce serait vraiment dommage d'utiliser les fonctions horriblement lentes du TIOS)

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.

Est-ce qu'il y a des switch pour activer le contrôle de débordement des entiers comme en Java ? (puisque je présume que c pas activé par défaut)

* En Java, ce n'est pas le contrôle qu'il y a par défaut, mais le wraparound.
* Pour le wraparound, il faudra attendre -fwrapv dans GCC, qui n'existe pas encore (et je ne suis pas sûr qu'il sera implémenté, il y a eu des objections, portant à la fois sur la réalisabilité dans le code actuel - GCJ a des bogues connus à cause de ça - et sur le fait que ce soit ou non une bonne idée).
* Pour le contrôle, il y a -ftrapv, mais les routines pour gérer ça ne sont pas implémentées dans TIGCCLIB.

Enfin bon, j'ai pas eu le temps de regarder ça de plus près, mais si c pas trop inefficace, ça a l'air prometteur

C'est très très inefficace en taille!

Hippohmu
:

Et un compilo ARM ?

Un compilo *orienté Hp49g+*, non. (pas encore)

Si tu veux un portage de GCC, je t'ai déjà proposé mon aide. Le linker de Sebastian risque de vous être très utile. (Le code spécifique au 68k peut être viré par des #ifdef, et tu peux peut-être ajouter des optimisations - suppression de relogements par exemple si c'est possible pour le ARM (je n'en sais rien) - en version ARM en te basant sur notre code pour le 68k.)

Quesoft
: D'ailleurs, la prochaine version devrait offrir un api ANSI qui pourra être compilé sous GCC et VC++.

Ça sonne bien. Mais n'oublie pas MinGW! C'est-à-dire, distingue bien entre les tests de compilateur (__GNUC__/_MSC_VER) et de système d'exploitation (_WIN32). Ne les mélange en aucun cas! (Je dis ça parce que j'ai vu beaucoup trop de personnes mettre:
#ifdef _WIN32
asm {
syntaxe M$
}
#endif
ou
#ifndef __GNUC__
#include <windows.h>
#endif
qui ne conviennent pas du tout. )

Pollux
:

J'alloue avec l'alias malloc de HeapAlloc. Comme je suis pas skillé en assembleur 68000 (en fait le seul assembleur que je connais est celui de la z architecture !), je ne vois pas une autre façon d'implémenter cette fonction.

Pas besoin de le faire en assembleur, du C suffirait Mais c vrai que c un peu long à faire...

Il n'y a pas vraiment de manière de faire ça proprement. Tu veux le faire comment, le mapping blocs utilisateur -> blocs AMS? Allouer des blocs de 65520 octets à AMS et allouer tes blocs en first fit? Ça gaspille énormément de place si les blocs utilisateurs font 32 KO chacun. Allouer un seul bloc de 65520 octets à AMS et tout mettre dedans? Dans ce cas, si on veut 2 blocs de 32 KO, tu fais quoi? Allouer un bloc de AMS pour chacun de tes blocs? Ben, alors ta "gestion personnalisée" du heap n'en est pas une et ne sert à rien. Il n'y a pas de bonne solution.

Raaah, comme d'habitude, dès qu'on parle de compilateurs: blabla blabla GTC blabla blabla Pollux blabla blabla...

et que dis-tu quand on parle de TIGCC dès qu'on parle de compilateur ?
c'est vrai que qu'il aurait également fallu parler de TI FS, mais bon, GTC a l'air plus prometteur

"GTC" (y-en a marre du typosquat, soit dit en passant)

en même temps, tu ne peux pas imposer à Pollux le nom de son projet

n'existe pas, n'a jamais existé et n'existera probablement jamais.

tu t'avances beaucoup je trouve

Et je ne vois pas pourquoi il devrait perdre son temps pour supporter ce compilateur en tant que backend alors qu'il y a TIGCC qui marche très bien.

il marche sur TI, TIGCC ?

Il marche pour TI, et c'est ça l'essentiel.

Euh y a pas un topic pour GTC quelque part.

Kevin Kofler :
Il marche pour TI, et c'est ça l'essentiel.

c'est là où tu fais fausse route, certains ont un accès limité aux ordinateurs mais pas à leur calculatrice, pour eux, un compilo uniquement pour TI n'est pas suffisant il faut aussi qu'il sache s'en contenter comme environnement de compilation

Kevin Kofler :
Ça sonne bien. Mais n'oublie pas MinGW! C'est-à-dire, distingue bien entre les tests de compilateur (__GNUC__/_MSC_VER) et de système d'exploitation (_WIN32). Ne les mélange en aucun cas! (Je dis ça parce que j'ai vu beaucoup trop de personnes mettre:
#ifdef _WIN32
asm {
syntaxe M$
}
#endif
ou
#ifndef __GNUC__
#include <windows.h>
#endif
qui ne conviennent pas du tout. )

Si la prochaine version offre un API ANSI, il sera assez menu dans un premier temps (pas d'API graphique entre autres). J'ai downloadé MinGW il y a un certain temps juste pour y jetter un coup d'oeil, mais je ne l'ai jamais utilisé. Il doit comprendre la bibliothèque standard, non ?

Kevin Kofler :
Il n'y a pas vraiment de manière de faire ça proprement. Tu veux le faire comment, le mapping blocs utilisateur -> blocs AMS? Allouer des blocs de 65520 octets à AMS et allouer tes blocs en first fit? Ça gaspille énormément de place si les blocs utilisateurs font 32 KO chacun. Allouer un seul bloc de 65520 octets à AMS et tout mettre dedans? Dans ce cas, si on veut 2 blocs de 32 KO, tu fais quoi? Allouer un bloc de AMS pour chacun de tes blocs? Ben, alors ta "gestion personnalisée" du heap n'en est pas une et ne sert à rien. Il n'y a pas de bonne solution.

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.

En passant, M. Kofler, alors que j'implémentais de nouvelles optimisations, suite à vos suggestions/critiques, j'ai découvert une lacune dans le processus d'optimisation. Cette lacune ne cause pas d'instabilité ou de lenteur, mais la prochaine version de Moka devrait générer des programmes plus petits.

Quesoft
:

Kevin Kofler :
Ça sonne bien. Mais n'oublie pas MinGW! C'est-à-dire, distingue bien entre les tests de compilateur (__GNUC__/_MSC_VER) et de système d'exploitation (_WIN32). Ne les mélange en aucun cas! (Je dis ça parce que j'ai vu beaucoup trop de personnes mettre:
#ifdef _WIN32
asm {
syntaxe M$
}
#endif
ou
#ifndef __GNUC__
#include <windows.h>
#endif
qui ne conviennent pas du tout. )

Si la prochaine version offre un API ANSI, il sera assez menu dans un premier temps (pas d'API graphique entre autres). J'ai downloadé MinGW il y a un certain temps juste pour y jetter un coup d'oeil, mais je ne l'ai jamais utilisé. Il doit comprendre la bibliothèque standard, non ?

Oui. Si tu n'as pas du tout besoin de #ifdef, et que tu gères GCC et Windows, il n'y aura aucun problème avec la combinaison, c'est-à-dire MinGW. Le problème ne survient que s'il y a des #ifdef qui associent erronément GCC=Unix et Windows=VC alors que MinGW=GCC+Windows. Un autre problème est celui des makefiles, mais il y a MSYS pour utiliser les makefiles Unix avec MinGW, donc normalement tu n'as pas besoin de gérer MinGW spécialement sous ce point de vue-là.

En passant, M. Kofler, alors que j'implémentais de nouvelles optimisations, suite à vos suggestions/critiques, j'ai découvert une lacune dans le processus d'optimisation. Cette lacune ne cause pas d'instabilité ou de lenteur, mais la prochaine version de Moka devrait générer des programmes plus petits.

En passant, tu peux m'appeler "Kevin". Mais c'est comme tu veux.

Kevin Kofler :
Oui. Si tu n'as pas du tout besoin de #ifdef, et que tu gères GCC et Windows, il n'y aura aucun problème avec la combinaison, c'est-à-dire MinGW. Le problème ne survient que s'il y a des #ifdef qui associent erronément GCC=Unix et Windows=VC alors que MinGW=GCC+Windows. Un autre problème est celui des makefiles, mais il y a MSYS pour utiliser les makefiles Unix avec MinGW, donc normalement tu n'as pas besoin de gérer MinGW spécialement sous ce point de vue-là.

J'en prend bonne notte.

Kevin Kofler :
En passant, tu peux m'appeler "Kevin". Mais c'est comme tu veux.

Ok Kevin

Kevin Kofler :
* En Java, ce n'est pas le contrôle qu'il y a par défaut, mais le wraparound.

Je ne comprend pas trop à quoi ça correspond ces deux choses

contrôle d'overflow: 2000000000+2000000000 -> erreur
wraparound: 2000000000+2000000000=-294967296
C standard: 2000000000+2000000000 -> "impossible", valeur complètement indéterminée

vince
: A tu prévu des interfaces avec GTC ? (gtc est le compilateur C oncalc de Pollux)

Et je ne vois pas pourquoi il devrait perdre son temps pour supporter ce compilateur en tant que backend alors qu'il y a TIGCC qui marche très bien.

On t'a déjà dit de sortir de ton monde utopiste, mon Kevin chéri... Si tu n'avais pas vu le coup de gueule de NiI avant qu'il soit locké, je peux te le montrer, je l'ai gardé...
On t'a déjà expliqué mille fois l'intérêt de la concurrence. On sait que pour toi il faudrait UN système d'exploitation, UN compilateur, UN constructeur d'ordinateurs, UN parti politique (les opposants sont censurés comme Pollux dans ton topic l'autre jour)...
Mais s'il te plaît, fait au moins semblant de comprendre que pour les gens normaux la diversité a un intérêt...

Pollux :
A propos du tas, est-ce que : - tu alloues avec HeapAlloc/HeapFree ou tu as fais des fonctions plus efficaces ? (ce serait vraiment dommage d'utiliser les fonctions horriblement lentes du TIOS)

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.

Non, ça procure de la vitesse. Ce n'est pas nul. Pour quelqu'un qui ne cherche que de l'optimisation en taille comme toi, c'est inutile, effectivement. Mais pour d'autres personnes ça peut être très intéressant.
Encore une fois, essaie de ne pas prendre tes opinions pour des vérités incontestables... sors de ta bulle, rends-toi compte que tu vis avec 6 milliards de presonnes, que t'as 6 milliards d'opinions autour de toi, et que personne ne peut prétendre avoir une pensée meilleure que celle des 5999999999 autres.

Enfin bon, j'ai pas eu le temps de regarder ça de plus près, mais si c pas trop inefficace, ça a l'air prometteur

C'est très très inefficace en taille!

C'est cool d'être honnête.
Mais ça n'empêche pas de faire des compliments ou des encouragements sympathiques, comme "bravo, tu as fait un travail énorme penses-tu pouvoir optimiser en taille prochainement ?"

Toujours aussi humble le Kevin...

Quesoft : tu as pensé faire un traducteur C++ -> C plus tard ? vu la base que tu viens de fournir, je pense que tu pourrais donner quelque chose de très intéressant

Albert Instinct :
tu as pensé faire un traducteur C++ -> C plus tard ? vu la base que tu viens de fournir, je pense que tu pourrais donner quelque chose de très intéressant

En fait, je crois que je vais plutôt continuer à améliorer Moka. Il n'a pas la maturité de TIGCC, et ne l'atteindra peut-être jamais, mais je crois que c'est un outil fort utile.

Si quelqu'un veut faire un traducteur C++ -> C, je ne m'en offusquerai pas ... mais je prétendrai que le Moka est plus efficient que le C++ Sans blague, Moka est distribué sous la license GNU et ce n'est pas pour rien : si mon travail peut aider à développer un traducteur C++, je serai le premier content.

rah mais bordel kevin....

Raaah, comme d'habitude, dès qu'on parle de compilateurs: blabla blabla GTC blabla blabla Pollux blabla blabla...

Raaah, comme d'habitude, dès qu'on parle de compilateurs: blabla blabla TIGCC blabla blabla Pollux blabla blabla...

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...

...

t'es con.

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.

toi t'es dans la premiere partie. quand t'aura fait un grand pas et admis que certaines personnes preferent la deuxieme, tu pourra peut etre esperer arriver a la 3eme un jour... des fois j'ai pitie pour toi de voir a quel point t'es borne et orgeuilleux...
tes parents t'ont fait passer un test de QI quand t'etais petit, t'ont donne le resultat, et maintenant t'as la grosse tete?

#ifdef _WIN32
asm {
syntaxe M$
}

depuis quand c'est la syntaxe "M$"? la derniere fois que j'ai regarde c'etait la syntaxe intel, qu'utilise le compilateur de ms... chose logique quand tu compile sur x86 soit dit en passant... pas comme la.. "syntaxe 6<C"
(et mettre un s a la place du dollar ca te demanderait bcp plus d'efforts? c vrai faut appuyer sur shift et monter un peu plus le doigt... )

pis me dit pas que pour le 68k c'est mieux la syntaxe gnu, pke deja je doute que tu fasse des.. "#include <windows.h>" sur ti, mais j'ai jamais dit que la syntaxe gnu puait dans tous les cas, contrairement a toi pour la syntaxe intel. la syntaxe gnu pue.. pour l'asm x86...

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!

Il marche pour
TI, et c'est ça l'essentiel.

bah non justement

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 et je suis sur qu'il est loin d'etre mauvais...

En passant, M. Kofler, alors que j'implémentais de nouvelles optimisations, suite à vos suggestions/critiques, j'ai découvert une lacune dans le processus d'optimisation. Cette lacune ne cause pas d'instabilité ou de lenteur, mais la prochaine version de Moka devrait générer des programmes plus petits.

En passant, tu peux m'appeler "Kevin". Mais c'est comme tu veux.

et la il est tout content le kevin l'homme a l'ego surdimensionne... moi on me parlerait comme ca, ca me mettrait mal a l'aise, lui non, il aime ca mon petit sucre d'orge Kevinichou
tu peux l'appeller "KK" aussi
mais chais pas pkoi il y voit une connotation pejorative...

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
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

nc et ras

Au fait, Pollux : j'ai accès à ton répertoire /gtcx en lecture. Je ne sais pas dans quelle mesure il s'agit de GTC et de toute façon ce n'est pas moi qui vais tout recopier, mais si tu ne tiens pas à diffuser ça, tu devrais faire attention

Bon, avant tout, je refuse de répondre à Thibaut dans la mesure où il continue à me diffamer en me faisant passer pour un extrémiste.

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 pour
TI, et c'est ça l'essentiel.

bah non justement

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.