60

> car PedroM est (horriblement?) optimisé taille
Ben non, puisque tu as mis la version rapide de ttunpack, vilain roll
Tu n'as pas choisi la version plus de deux fois plus petite (et plus lente à peu près dans la même proportion). Kevin, lui, au moins, a eu la grande finesse de choisir la version petite/lente pour tous les lanceurs spécifiques pour programmes compressés PPG, lanceurs dupliqués en un nombre variable d'exemplaires sur les machines en circulation (c'est bien pour ça qu'il faut les optimiser taille !).



(et oui, je sais où est la sortie et d'ailleurs, j'y vais tout de suite grin
J'ai pas pu résister, c'est tout grin)
avatarMembre de la TI-Chess Team.
Co-mainteneur de GCC4TI (documentation en ligne de GCC4TI), TIEmu et TILP.
Co-admin de TI-Planet.

61

./59: Bon l'option '-g' est totalement (pas tout à fait) incompatible avec l'option '--flash-os'.
Lionel Debroux (./60) :
> car PedroM est (horriblement?) optimisé taille Ben non, puisque tu as mis la version rapide de ttunpack, vilain


s/est/était/
Il devient beaucoup plus modulaire. Surement plus gros aussi.

Nouveau build :
Program Statistics:
  Program Variable Name:                    main\pedrom
  Program Variable Size:                    209987 Bytes
  BSS Size:                                 10234 Bytes
  Absolute Relocs:                          0
  Natively Emitted Relocs:                  0
  Relocs Removed by Branch Optimization:    1111
  Relocs Removed by Move Optimization:      465
  Relocs Removed by Test Optimization:      21
  Relocs Removed by Calc Optimization:      14
  Relocs Removable by F-Line Jumps:         3277
  Space Saved by Range-Cutting:             1946 Bytes

avec GMP 4.2.2 et MPFR 2.3.1 grin
A mon avis, il y a un problème pour la section BSS. Elle est trop petite smile

Avec reorder-section:
Program Statistics:
  Program Variable Name:                    main\pedrom
  Program Variable Size:                    210271 Bytes
  BSS Size:                                 10234 Bytes
  Absolute Relocs:                          0
  Natively Emitted Relocs:                  0
  Relocs Removed by Branch Optimization:    900
  Relocs Removed by Move Optimization:      391
  Relocs Removed by Test Optimization:      21
  Relocs Removed by Calc Optimization:      14
  Relocs Removable by F-Line Jumps:         4454
  Space Saved by Range-Cutting:             1598 Bytes

Rien à faire, toujours plus gros !

62

Perso, avec des petits sources (3 à 10 ko), ça marche. Mais je trouve dommage en effet que l'algorithme soit heuristique et non le meilleur possible.

Par exemple, la méthode actuelle consiste à grouper au centre du binaire les gros morceaux et à recoller sur les côtés les sections de plus en plus petites. Est-ce que ça veut donc dire qu'une section de 20 octets appelée 10 fois par une section des plus grosses (à supposer que tous les appels seraient à moins de 127 octets si les sections étaient accolées) verra tous ses appels par la grosse fonction faire 4 octets ? L'idéale serait de coller la petite fonction juste à côté de la grosse. J'imagine qu'il doit exister de meilleurs algorithmes (quitte à tout décrire, j'en ai rien à battre que la compilation prenne 4 secondes et non 2 ^^).

PpHd : ton code remanié depuis dépasse les 15~20 sections ? L'idéal ne serait pas d'avoir une section par fonction (par romcall, par fonction interne, par interuption etc...) ?
avatarMon journal de bord <flux rss manuel> asTI68k : WIP </flux>

Le modernisme ne diffère guère de la libre pensée absolue que par sa prétention de demeurer catholique.

63

Nouveau build/reorder section
Program Statistics:
  Program Variable Name:                    main\pedrom
  Program Variable Size:                    447527 Bytes
  BSS Size:                                 11038 Bytes
  Absolute Relocs:                          0
  Natively Emitted Relocs:                  0
  Relocs Removed by Branch Optimization:    1256
  Relocs Removed by Move Optimization:      889
  Relocs Removed by Test Optimization:      19
  Relocs Removed by Calc Optimization:      13
  Relocs Removable by F-Line Jumps:         27401
  Space Saved by Range-Cutting:             1414 Bytes

(En plus ca met 30s pour calculer / j'ose pas mettre --function-section).

Nouveau build/sans reorder section:
Program Statistics:
  Program Variable Name:                    main\pedrom
  Program Variable Size:                    447069 Bytes
  BSS Size:                                 11038 Bytes
  Absolute Relocs:                          0
  Natively Emitted Relocs:                  0
  Relocs Removed by Branch Optimization:    1427
  Relocs Removed by Move Optimization:      1023
  Relocs Removed by Test Optimization:      11
  Relocs Removed by Calc Optimization:      13
  Relocs Removable by F-Line Jumps:         26124
  Space Saved by Range-Cutting:             1946 Bytes

Toujours plus petit !

Sinon, c'est GMP 4.2.2 / MPFR 2.3.1 / MAYLIB 0.7.1 Mais il reste du boulot d'intégration pour que ca soit utilisable.

64

Martial Demolins (./62) :
PpHd : ton code remanié depuis dépasse les 15~20 sections ?

Oui. A peu près.
L'idéal ne serait pas d'avoir une section par fonction (par romcall, par fonction interne, par interuption etc...) ?

Oui mais je sens que ca va pas le faire sur un projet aussi gros.
Martial Demolins (./62) :
quitte à tout décrire, j'en ai rien à battre que la compilation prenne 4 secondes et non 2 ^^).

Et 4 H ?

65

Oué, on est peut-être pas non plus dans cette proportion cheeky Quitte à compiler avec cette option pour releaser (mais c'est peut-être pas viable pour les tests que tu fais?).

Pour définir les section, j'utilise des macros, un mot et c'est terminé, définition et export, ça reste jouable au niveau travail à faire. Après, je ne sais pas quelles sont tes exigences par rapport à ton code, jusqu'où tu veux permettre au linker de te déplacer des trucs sans te demander ton avis...
avatarMon journal de bord <flux rss manuel> asTI68k : WIP </flux>

Le modernisme ne diffère guère de la libre pensée absolue que par sa prétention de demeurer catholique.

66

Nouveau build:
Program Statistics:
  Program Variable Name:                    main\pedrom
  Program Variable Size:                    492193 Bytes
  BSS Size:                                 11038 Bytes
  Absolute Relocs:                          0
  Natively Emitted Relocs:                  0
  Relocs Removed by Branch Optimization:    1953
  Relocs Removed by Move Optimization:      1327
  Relocs Removed by Test Optimization:      13
  Relocs Removed by Calc Optimization:      13
  Relocs Removable by F-Line Jumps:         28415
  Space Saved by Range-Cutting:             1946 Bytes


J'ai intégré tout ce que j'avais à intégrer. Il me reste à finir (définir ces fonctions:
	xdef	__floatunssibf
	xdef	__fixunsbfsi
	xdef	__nebf2
	xdef	__eqbf2
	xdef	__addbf3
	xdef	__gtbf2
	xdef	__ltbf2
	xdef	__gebf2
	xdef	__negbf2
	xdef	__divbf3
	xdef	__lebf2

) et tester sick
Premier test:
Sans argument: on affiche le menu d'aide et poum "system error"
Avec 2, poum "error(panik)"
Avec x, poum "System Error"
J'ai du boulot smile
Martial Demolins (./65) :
Oué, on est peut-être pas non plus dans cette proportion

Si on veut faire exhaustivement, peut être que si smile
Martial Demolins (./65) :
Quitte à compiler avec cette option pour releaser (mais c'est peut-être pas viable pour les tests que tu fais?).

C'est pas 100% représentatif, mais ca peut aider.
Martial Demolins (./65) :
Pour définir les section, j'utilise des macros, un mot et c'est terminé, définition et export, ça reste jouable au niveau travail à faire. Après, je ne sais pas quelles sont tes exigences par rapport à ton code, jusqu'où tu veux permettre au linker de te déplacer des trucs sans te demander ton avis...

Tant que ca marche, il peut faire ce qu'il veut.

67

PpHd (./59) :
Et je suis désolé, mais le linkeur ne devrait pas échouer s'il y a un ordre valide ! Il FAUT tester lorsqu'on réordonne les sections, si le nouvel ordre est valide, ie si toutes les relocs relatives restent possibles avec ce nouvel ordre !

J'avais fait ça dans mon implémentation d'origine. Le problème, c'était que:
* le backtracking pouvait prendre un temps superexponentiel (facteur n_sections! dans le pire des cas). Surtout sur quelque chose d'aussi gros qu'un Flash OS, ça va être totalement inacceptable.
* ça ne marche pas avec l'heuristique plus rapide et plus efficace (programmes plus petits) de Sebastian. Mon heuristique était une heuristique locale qui composait le programme du début à la fin, c'est facile de backtracker dans ce cas, celle de Sebastian repose sur des considérations plus globales. Cela dit, il est possible que cette heuristique marche effectivement mal pour les programmes de plus de 64 KO, elle n'a pas été testée sur un Flash OS parce qu'on n'avait pas de Flash OS en plusieurs sections sur lequel on aurait pu la tester.
Sinon ca ne sert à rien.

Bah si, il suffit de corriger ton code. Les sections sont des unités totalement indépendantes, une section n'a pas le droit de présupposer qu'une autre section va se retrouver immédiatement devant ou derrière.
Et sinon ca ne sert pas à grand chose:
Avec: 121337Sans: 120975

Bah, désactive-le alors et arrête de te plaindre.

Je ne peux pas faire un réarrangeur de sections parfait, la complexité de l'algorithme évident serait en au moins O(n_sections! * polynom(n_relocs)), c'est totalement intenable, et je ne pense pas qu'il soit possible de le faire en moins de O(2^n_sections), ce qui est déjà inacceptable (et même là, je ne suis pas sûr que ce soit possible). Si tu sais faire mieux, j'attends ton algorithme. tongue Et aussi la démonstration de P=NP qui va sans doûte en découler. gni
avatarMes news pour calculatrices TI: Ti-Gen
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité

68

Kevin Kofler (./67) :
Bah si, il suffit de corriger ton code. Les sections sont des unités totalement indépendantes, une section n'a pas le droit de présupposer qu'une autre section va se retrouver immédiatement devant ou derrière.

C'est déjà fait.
Kevin Kofler (./67) :
Bah, désactive-le alors et arrête de te plaindre.

C'est déjà fait.
Kevin Kofler (./67) :
Je ne peux pas faire un réarrangeur de sections parfait, la complexité de l'algorithme évident serait en au moins O(n_sections! * polynom(n_relocs)), c'est totalement intenable, et je ne pense pas qu'il soit possible de le faire en moins de O(2^n_sections), ce qui est déjà inacceptable (et même là, je ne suis pas sûr que ce soit possible). Si tu sais faire mieux, j'attends ton algorithme. tongue.gif Et aussi la démonstration de P=NP qui va sans doûte en découler. gni.gif

C'est pas fait.

69

70

Ok, ok.

Nouveau build en utilisant cut-range et optimize-code partout dans les libs:
tigcc -v --flash-os --flash-os-bss-start=0x5B00 --outputbin --cut-ranges --optimize-code PedroM.89.o PedroM2.89.o Bss.89.o c/files.89.o c/printf.89.o c/clipline.89.o c/bitmap.89.o c/qsort.89.o c/md5.89.o c/float.89.o c/ellipse.89.o c/side.89.o lib/gmp-4.2.2/.libs/libgmp.a lib/mpfr-2.3.1/.libs/libmpfr.a lib/may/libmay.a            lib/may/t-pika.o -o PedroM 
tigcc: /home/pphd/tigcc/bin/ld-tigcc -v --flash-os --flash-os-bss-start=0x5B00 --cut-ranges --optimize-code PedroM.89.o PedroM2.89.o Bss.89.o c/files.89.o c/printf.89.o c/clipline.89.o c/bitmap.89.o c/qsort.89.o c/md5.89.o c/float.89.o c/ellipse.89.o c/side.89.o lib/may/t-pika.o lib/gmp-4.2.2/.libs/libgmp.a lib/mpfr-2.3.1/.libs/libmpfr.a lib/may/libmay.a /home/pphd/tigcc/lib/flashos.a -o PedroM --           outputbin
Warning: Flash OS support in TIGCC is experimental.
Target Calculators:
  TI-89
Program Statistics:
  Program Variable Name:                    main\pedrom
  Program Variable Size:                    487687 Bytes
  BSS Size:                                 11038 Bytes
  Absolute Relocs:                          0
  Natively Emitted Relocs:                  0
  Relocs Removed by Branch Optimization:    1963
  Relocs Removed by Move Optimization:      1335
  Relocs Removed by Test Optimization:      13
  Relocs Removed by Calc Optimization:      13
  Relocs Removable by F-Line Jumps:         28352
  Space Saved by Range-Cutting:             6886 Bytes
mv -f PedroM-89.tib ..

real    2m0.182s
user    1m55.787s
sys     0m0.740s


==> Le temps pour créer la ROM devient problématique ! Je crois que les limites de ld-tigcc deviennent très visibles.

[EDIT]: Petit screenshot de l'avancement :
EvDv U5NI W34y

71

Bon avancement smile
Mais c'est sûr que le temps de compilation+link devient difficilement acceptable... C'est le reorder-sections qui prend la plupart de ce temps, j'imagine ?

[EDIT:
Relocs Removable by F-Line Jumps: 28352
sick]
avatarMembre de la TI-Chess Team.
Co-mainteneur de GCC4TI (documentation en ligne de GCC4TI), TIEmu et TILP.
Co-admin de TI-Planet.

72

Ça ne sert à rien dans un Flash OS, les F-Line Jumps! Ça élimine juste les relogements, ce qui ne sert à rien dans un Flash OS où les relogements sont résolus au moment du linking.

Et ces temps, c'est sans --reorder-sections.
avatarMes news pour calculatrices TI: Ti-Gen
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité

73

C'est --cut-range et --optimize-code qui font monter à 2 minutes. Sans, çà doit être de l'ordre de 20s.

74

Euh... je compile la bêta courante en beaucoup moins de temps eek
Peut-être deux secondes ?
avatarMon journal de bord <flux rss manuel> asTI68k : WIP </flux>

Le modernisme ne diffère guère de la libre pensée absolue que par sa prétention de demeurer catholique.

75

Tu génères un exécutable d'un demi-méga ? (Regarde les screenshots).

76

Oui, je ne parle que "d'un programme de 120ko" © cheeky
avatarMon journal de bord <flux rss manuel> asTI68k : WIP </flux>

Le modernisme ne diffère guère de la libre pensée absolue que par sa prétention de demeurer catholique.

77

Constitué d'un seul asm. Contre un qui est constitué de 992 fichiers C et 370 fichiers asm.

78

ah oué tu l'as modularisé en effet hehe

79

Il a surtout rajouté une grosse usine à gaz de calcul formel basée sur GMP et MPFR...
avatarMes news pour calculatrices TI: Ti-Gen
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité

80

Au moins ca calcule 3000! de manière exacte sur TI, pas comme AMS qui refuse même de l'évaluer en flottant tongue

81

Ça ne sert à rien dans un Flash OS, les F-Line Jumps! Ça élimine juste les relogements, ce qui ne sert à rien dans un Flash OS où les relogements sont résolus au moment du linking.

Je sais, mais ça montre qu'il y a _beaucoup_ de xxx.l: en moyenne, plus d'un octet sur 5 dans PedroM est une référence xxx.l !
(et encore, le linker en a déjà optimisé plus de 3000 xxx.l, en plus du range-cutting)

PedroM est probablement un bon exemple pour faire du profiling de --cut-ranges, --optimize-code, --reorder-sections grin


La syntaxe de l'environnement de calcul formel est pas super user-friendly, je trouve grin


Il y a un repository d'un SCM quelconque où on puisse accéder au source ?
avatarMembre de la TI-Chess Team.
Co-mainteneur de GCC4TI (documentation en ligne de GCC4TI), TIEmu et TILP.
Co-admin de TI-Planet.

82

Lionel Debroux (./81) :
Je sais, mais ça montre qu'il y a _beaucoup_ de xxx.l: en moyenne, plus d'un octet sur 5 dans PedroM est une référence xxx.l ! (et encore, le linker en a déjà optimisé plus de 3000 xxx.l, en plus du range-cutting)

Tiens c'est vrai. Ca me parait étrange quand même un tel taux. Mais c'est pas impossible.
Lionel Debroux (./81) :
PedroM est probablement un bon exemple pour faire du profiling de --cut-ranges, --optimize-code, --reorder-sections biggrin.gif

Surement.
Lionel Debroux (./81) :
La syntaxe de l'environnement de calcul formel est pas super user-friendly, je trouve biggrin.gif

C'est exactement la même syntaxe que celle du petit outil fournit avec MAYLIB.
Forcément, c'est le même outil.
On m'a promis une super interface de la mort qui tue smile
Lionel Debroux (./81) :
Il y a un repository d'un SCM quelconque où on puisse accéder au source ?

Oui, mais non public smile
Sinon, ca utilise GMP / MPFR / MAYLIB qui sont tous disponibles.

[EDIT]: Nouveau screenshot: rwn3
Note: Le "CPU time" donné est faux.

Comparaison AMS et PedroM:
9817 V42t0tS8
C'est trop gros pour rentrer à l'écran. Mais il le calcule smile

83

Bien joué !
Bon, tu nous porte un outil de géométrie maintenant ? gni
avatarQue cache le pays des Dieux ? - Ximoon's Box - Forum Ghibli - Forum Littéraire

La fin d'un monde souillé est venue. L'oiseau blanc plane dans le ciel annonçant le début d'une longue ère de purification. Détachons-nous à jamais de notre vie dans ce monde de souffrance. Ô toi l'oiseau blanc, l'être vêtu de bleu, guide nous vers ce monde de pureté. - Sutra originel dork.

84

Vu qu'il n'y a pas --reorder-sections, je conclurais de ./56, ./61 et ./70 que la plupart des relocations sont dans le code récemment rajouté, c'est à dire dans les fonctions qui ne sont pas le coeur de PedroM.
S'il n'y en a pas déjà, ça ne serait certainement pas très lourd en termes de performance de rajouter des wrappers qui ne font qu'un jmp, pour des fonctions telles que HeapAllocPtr/HeapFreePtr, memset, memcpy et quelques autres, non ?


> Note: Le "CPU time" donné est faux.
Bouh, je suis déçu... je croyais que l'éval float de 3000! prenait vraiment ce temps-là mourn
avatarMembre de la TI-Chess Team.
Co-mainteneur de GCC4TI (documentation en ligne de GCC4TI), TIEmu et TILP.
Co-admin de TI-Planet.

85

Ximoon (./83) :
Bon, tu nous porte un outil de géométrie maintenant ? gni.gif

Il reste plein de choses à faire avant : intégration, matrices, solveur,limite, langage, UI
Et j'ai jamais vu un intérêt à leur outil de géométrie.
Lionel Debroux (./84) :
Vu qu'il n'y a pas --reorder-sections, je conclurais de ./56, ./61 et ./70 que la plupart des relocations sont dans le code récemment rajouté, c'est à dire dans les fonctions qui ne sont pas le coeur de PedroM.

--reorder-sections ne fait qu'augmenter la taille du binaire. Donc je ne l'utilise pas.
Lionel Debroux (./84) :
S'il n'y en a pas déjà, ça ne serait certainement pas très lourd en termes de performance de rajouter des wrappers qui ne font qu'un jmp, pour des fonctions telles que HeapAllocPtr/HeapFreePtr, memset, memcpy et quelques autres, non ?

J'ai propose à Kevin cette amélioration. Je te laisse patcher le linkeur pour grin
Lionel Debroux (./84) :
Bouh, je suis déçu... je croyais que l'éval float de 3000! prenait vraiment ce temps-là pleure.gif

Tu n'as pas tout compris. Ca calcule de manière exacte 3000! puis le convertie en floattant. Et ca met 6s sur emu (avec RestrictActualSpeed).
Avec 3000.!, ca met 2s (et ca donne exactement le même résultat - MPFR no powa !).

86

PpHd (./85) :
Ximoon (./83) :
Bon, tu nous porte un outil de géométrie maintenant ? gni.gif

Il reste plein de choses à faire avant : intégration, matrices, solveur,limite, langage, UI
Et j'ai jamais vu un intérêt à leur outil de géométrie.


Ah mais y'a rien dans ton truc alors embarrassed (j/k tongue)

Un outil de géométrie ? Ça sert à faire de beaux screens pour les plaquettes publicitaires oui
avatarQue cache le pays des Dieux ? - Ximoon's Box - Forum Ghibli - Forum Littéraire

La fin d'un monde souillé est venue. L'oiseau blanc plane dans le ciel annonçant le début d'une longue ère de purification. Détachons-nous à jamais de notre vie dans ce monde de souffrance. Ô toi l'oiseau blanc, l'être vêtu de bleu, guide nous vers ce monde de pureté. - Sutra originel dork.

87

J'ai propose à Kevin cette amélioration. Je te laisse patcher le linkeur pour grin

Ca fait déjà bien trois ans que j'ai commencé à ajouter (mais jamais fini) le support pour le timestamp de compilation, utilisable dans PedroM et Punix... je vais peut-être finir ça d'abord grin

(Mais ça ne sera probablement pas pour ce week-end: j'ai dit le week-end dernier à un programmeur de user-space que je regarderais probablement le week-end dernier pourquoi son programme ch**, mais je ne l'ai toujours pas véritablement fait...)
avatarMembre de la TI-Chess Team.
Co-mainteneur de GCC4TI (documentation en ligne de GCC4TI), TIEmu et TILP.
Co-admin de TI-Planet.

88

PpHd (./85) :
Et j'ai jamais vu un intérêt à leur outil de géométrie.
Ximoon (./86) :
Un outil de géométrie ? Ça sert à faire de beaux screens pour les plaquettes publicitaires

pencil Déjà essayé leur truc, jamais vu l'intérêt... C'est du AutoCAD-like vu de loin, mais loin de l'être
PpHd (./85) :
Avec 3000.!, ca met 2s

eek La vache !!! Chapeau la perf !
avatarMon journal de bord <flux rss manuel> asTI68k : WIP </flux>

Le modernisme ne diffère guère de la libre pensée absolue que par sa prétention de demeurer catholique.

89

Lionel Debroux (./87) :
Ca fait déjà bien trois ans que j'ai commencé à ajouter (mais jamais fini) le support pour le timestamp de compilation, utilisable dans PedroM et Punix... je vais peut-être finir ça d'abord


Tu as une semaine !

90

PpHd (./89) :
le support pour le timestamp de compilation

Qu'est-ce que c'est? cheeky
avatarMon journal de bord <flux rss manuel> asTI68k : WIP </flux>

Le modernisme ne diffère guère de la libre pensée absolue que par sa prétention de demeurer catholique.