Progs en C - Page 3

#55 > Merci (effectivement j'avais oublié le problème du cout énorme en RAM qu'une méthode "normale" obligerait)

[Edit] Rien :]

Thibaut :
Pollux redimensionne peut-être le twin pour qu'il ne reste que le code du launcher. Comme ça, le handle ne change pas, et le TIOS doit n'y voir que du feu

Tiens, pas mal comme idée ça.
Ça reste sale, mais c'est bien stable à ce qu'il me semble.
Je vais proposer ça à Lionel pour ExePack.

Ha ! tu vois qu'il ne faut pas croire que tu as toujours les meilleures idées


Vertyos : pourquoi tu me dis ça ?

cf edit j'avais raté le dernier post de GoldenCrystal, page précedente :]

En considérant la technique du redimentionnement du handle, le seul inconvenient qu'il reste avec les données inclues au lanceur c'est donc qu'on perd 1200 octets de données compressées ? (soit je-sais-pas-cb de plus en équivalent non compressé)

(perdre = par rapport à la limite des 24k)

./47> ben avec la compression EXE

./53>

Le lanceur qui décharge sa copie en cours d'exécution, c'est un hack assez sale (qui a été refusé pour ExePack parce qu'il est trop sale, les logiciels de la TICT ayant la réputation d'être programmés proprement).

Pas si c'est bien fait. Evidemment si je faisais :

void _main() {
  void *prog=HeapAllocAndDecompress();
  HeapFree(Ptr2hd(_main));
  run(prog);
  HeapFreePtr(prog);
}

ça ferait assez mal Mais j'ai bien fait attention au ghost space et tout ça. Après si tu qualifies tout ce qui touche au ghost space de sale, évidemment c'est sale mais c'est pareil pour ttstart.

Pollux redimensionne peut-être le twin pour qu'il ne reste que le code du launcher. Comme ça, le handle ne change pas, et le TIOS doit n'y voir que du feu

Effectivement, le TIOS n'y verra que du feu, mais je supprime carrément le twin (sinon ça ferait un gros trou dans la mémoire haute, et comme la mémoire haute est dans le mauvais sens d'allocation pour se prêter à ce genre de chose, ça pourrait être assez catastrophique). Enfin, pas vraiment à cause du code de lancement du TIOS, mais c'est comme si

Et bien il ne fait rien Que ce soit avec ttstart ou la méthode de Pollux, il y a double-copie du programme dans ce cas !

A moins d'inclure un compresseur on-calc dans le launcher (5 ko de plus ) et d'être sûr que le programme ne modifie pas de données vitales, c'est pas gagné de ne pas avoir de double copie Et puis ça n'est qu'une 1.5x-copie

Vertyos> oui

[EDIT] : (cite) est plus adapté que (pre) pour les citations apparemment

...et donc problème pour l'AMS 2.03 par exemple, qui a la limite à 8ko :-/
En fait c'est à peu près le seul vrai problème par rapport à ttpack.

On peut toujours utiliser un launcher (par exemple ttstart )

Azur va latter GTC !

Thibaut> de quoi tu parles?

Thibaut
: Azur va latter GTC !

C'étaient les beaux temps quand tu travaillais tranquillement sur ton compilateur à toi plutôt que de passer ton temps à insulter le nôtre.

remarquez la date d'édition du post de thibaut, quel fourbe

Oué comme ça Kevin a cru que le #68 répondait à ma blague

Kevin Kofler :
C'étaient les beaux temps quand tu travaillais tranquillement sur ton compilateur à toi plutôt que de passer ton temps à insulter le nôtre.

A part la fois avec l'histoire de _rowread où je me suis excusé, je ne vois pas quand est-ce que j'ai insulté ton travail, Kevin
Je respecte TIGCC autant que GTC.

Mais j'ai plus d'admiration pour GTC parcequ'il est très complet et performant pour un si petit compilo.

Thibaut
:

Kevin Kofler :
C'étaient les beaux temps quand tu travaillais tranquillement sur ton compilateur à toi plutôt que de passer ton temps à insulter le nôtre.

A part la fois avec l'histoire de _rowread où je me suis excusé, je ne vois pas quand est-ce que j'ai insulté ton travail, Kevin Je respecte TIGCC autant que GTC.

Tu respectes peut-être mon travail, mais tu ne respectes pas ma personne. Et en plus tu insultes l'équipe entière ("la mentalité de [...] de l'équipe de TIGCC" etc.) alors que Sebastian (ni Zeljko etc.) n'y est pour rien quand tu me détestes, moi.

C'est tout de même plus ou moins réciproque Et XDanger qui mélange Thibaut et la France entière est encore bien pire.

Kevin > tu ne respectes pas ma personne
Oui
Pollux > C'est tout de même plus ou moins réciproque
Clair !

Kevin : tu a(vai ?)s un comportement difficilement respectable.

Voilà Einstein est compilé. GTC confirme une nouvelle fois qu'il est le meilleur en optimisation taille !
Mon shell prend 3,3 ko de RAM en moins quand on le lance !
Et il prend 3 ko de moins en ROM !

Non-compressés : 
  TIGCC : 33,02 ko (en -Os)
  GTC   : 29,7 ko 
 
Compressés : 
  TIGCC : 19,6 ko (en comptant le launcher) 
  GTC   : 16,6 ko (launcher intégré)

On peut aussi bencher la vitesse de chargement si on veut

y

(void _main() { }
#undef _main
#define _main dumm

)

Pas besoin de bencher la vitesse de décompression, c'est impossible !

Aussitôt qu'on tape einstein(), le shell s'ouvre !!!
Y'a pas plus de 500 ms d'attente à mon avis En tout cas, clairement beaucoup moins d'une seconde !

Avec TIGCC et le ttunpack personnalisé (1,6 ko) il faut attendre environ 1,5 s

Je ne vois pas comment un certain Monsieur Kernel Killer peut dire que GTC est inutile alors qu'il fait des programmes plus petits de plusieurs ko et plus rapides à se lancer...

j'aime bien tes jeux de mots

LOL c clair

Thibaut> j'aimerais bien avoir un bench un peu plus précis, à moins que ça te dérange d'attendre parce que GTC compile pdt 3 heures C pas compliqué de rajouter ces 3 lignes

> à moins que ça te dérange d'attendre parce que GTC compile pdt 3 heures
Tu voulais dire TIGCC, non ?

Non ct juste pour te dire que tu n'avais pas l'excuse du temps de compilation (ah oui tiens c un argument contre GTC ça, surtout Kevin note bien )

Thibaut :

Non-compressés : 
  TIGCC : 33,02 ko (en -Os)

* Quelle version de GCC? (tigcc --version, ou de préférence le numéro exact du prerelease si tu t'en rappelles (certains ont la même date de snapshot))
* As-tu pensé à mettre -fomit-frame-pointer?

J'ai cru constater que -fomit-frame-pointer donnait un code plus gros !?
Je vais essayer pour voir
Release .94 SP3

Thibaut
: J'ai cru constater que -fomit-frame-pointer donnait un code plus gros !?

Normalement (sur 68k) non (par exemple, pour Backgammon, ça diminue la taille), mais ça dépend toujours des cas.

Release .94 SP3

Avec le GCC livré (3.2.1-tigcc-2)? Ou avec GCC 3.3.x?

Autre truc à essayer avec GCC 3.3: -fno-if-conversion. Parfois, ça aide pour la taille, parfois ça empire.

19,85 ko avec -fomit-frame-pointer
J'ai pas GCC 3

moi g tjs gagné en place avec -fomit-frame-pointer

Thibaut :
19,85 ko avec -fomit-frame-pointer

Et la taille non-compressée?

J'ai pas GCC [3.3]

Ben, télécharge-le avant de râler sur la mauvaise optimisation de GCC! Ça fait longtemps que les prereleases sont disponibles, et la 3.3.1-pre18 fonctionne très bien (elle sera aussi la version inclue dans TIGCC 0.95 bêta 1, vraisemblablement).
GCC 3.3 optimise mieux que l'ancienne version.

Comme si une nouvelle version allait faire gagner plusieurs Ko (enfin, si c'était le cas ==> gcc est mal programmé)

Ouai, je ne pense pas que GCC 3 va me diminuer Einstein de 3,3 ko.

Kevin, j'irais DL plus tard, j'ai d'autres chose à faire là