pb ac l'expression stack - Page 2

Ou si vraiment tu n'acceptes pas d'attendre 3 secondes pour une compilation

Sous Windows 98, ce serait plus près d'une minute que trois secondes à mon avis
<excuse bidon="on">Maintenant il fonctionne, mais je garde -O0 en attendant, ça ralentit mon programme et augmente la taille et m'oblige donc à optimiser! </excuse bidon>

brunni > g posté la source + haut
KK > k thx

Brunni
:

Ou si vraiment tu n'acceptes pas d'attendre 3 secondes pour une compilation

Sous Windows 98, ce serait plus près d'une minute que trois secondes à mon avis

J'ai essayé de compiler de gros projets avec Windows 95 et Me et ce n'est pas si grave que ça, donc je ne pense pas que ce soit si lourd que ça avec Windows 98.

Ça dépend, quand j'avais Windows 98, un projet qui mettait une minute à compiler c'était pas extraordinaire.

pareil ; sous 98, 1min30
sous XP, même projet, même version de TIGCC, même PC, 30 secondes
(environ, à chaque fois, et ça date d'il y a bien deux ans)

<emulation=on>
Et alors, moi ça ne me dérange pas d'attendre 10 minutes pour une compilation.
</>

<tagueule target="Pollux"/>

Erf, ça aurait pas été la première fois que tu le disais, avoue

kk > t'a trouvé le pb ac la stack dans la source que je t'ai envoyé?

Non (pas encore eu le temps de regarder en détail).
Mais je pense que ton problème est que tu n'as mis la sauvegarde/restauration qu'à une de tes plusieurs boucles plaçant quelque chose sur la pile d'expression. Il faudra la mettre à toutes.

je l'ai mi la sauvagarde / rest&auration avant et apres 'lintyerpétation d'une commande multitache

Et voilà, ce n'est qu'une de tes boucles touchant à la pile d'expressions.

non c'est la seule

C'est peut-être la seule boucle, mais tu touches à la pile d'expression à pratiquement chaque appel de Exec_Command sans rien nettoyer. Au bout de suffisamment d'appels à cette fonction, la pile d'expressions est pleine. Il faut restaurer la valeur de top_estack récupérée au début de Exec_Command avant le prochain return.

y'non pasque la seule fonction qui appelle exec_command c exec_one et c la dedans que y'a la sauvagarde restore de la stack

Heu... ôte-moi d'un doute là... tu ne veux tout de même pas tokeniser des progs TI-BASIC sous leur forme texte (ligne par ligne) en temps réel et penser les exécuter ainsi non? Parce que le parsing est extrêmement lent, et maintenant si plusieurs tournent en même temps, alors là...

Brunni :
Heu... ôte-moi d'un doute là... tu ne veux tout de même pas tokeniser des progs TI-BASIC sous leur forme texte (ligne par ligne) en temps réel et penser les exécuter ainsi non? Parce que le parsing est extrêmement lent, et maintenant si plusieurs tournent en même temps, alors là...

Meuh si, j'avais fait un petit interpréteur pourri (en C, qui plus est) qui parsait en temps réel. Une petite dizaine de fois plus rapide que le Basic, si mes souvenirs sont bons. Mais c'est sûr que l'idéal c évidemment de compiler pour une machine virtuelle (et là on peut atteindre des vitesses bien supérieures).

Sauf que là il parse en temps réel en utilisant les fonctions du TIOS, et non son propre interpréteur. Et c'est là que c'est

Pollux>Et ont attend toujours la version ASM

Mac> La vapeur vaincra

kk > t'a trouvé qqch? pasque moi je vois tjs pa ou est le pb

Je viens de jeter un coup d'œil là-dessus. Ma conclusion:
* Ce n'est pas un bogue du compilateur. (J'ai vérifié le code généré et il est bon, même sans volatile.)
* Impossible de déboguer ton programme parce qu'il me manque plein de fichiers. (Tu ne m'as envoyé que les sources du programme principal, et ni la DLL, ni les applications.)
* Bref, je n'ai aucune idée d'où vient ton bogue.

Au fait, il faudra m'expliquer pourquoi tu utilises USE_KERNEL, vu que ton programme compile très bien sans.

USE_KERNEL c pasque + tard y'aura des librairies du style ziplib utilisées
att je t'envoie le DLL

kk > t'a trouvé qqch?

Non. Mais il faut dire que j'étais occupé par d'autres trucs en ces derniers temps.

-en