TIGCC 0.95 Beta 8 - Page 5

tient un autre truc abérant avec tigcc

Les exemples du .chm pronent l'utilisation des #define USE_TIxxx

pourtant avec le fonctionnement actuel de tigcc 0.95 le copier coller d'un code ne fonctionnera PAS (ou générera plein de warning) a cause de ces options automatiques (et qui ne devrait PAS etre automatique...)

Godzil, qu'est-ce que t'as à t'acharner comme ça sur TIGCC ?
OK, l'IDE n'est pas parfaite pour toi, la doc n'est peut-être pas partout à jour, mais rends-toi compte du boulot énorme que c'est, c'est normal que ce ne soit pas parfait...

Kevin >

*Alors tu les effaces.*
C'est justement ce qui est embêtant, surtout que je crois
que ça oblige beaucoup de monde à effacer.
(Sous-entendu timide: personne ne s'en sert)

*C'est justement le problème: personne ne l'utilise. Nous voulons encourager l'utilisation de cette feature.*
Désolé mais cette fois-ci je ne suis pas d'accord sur l'emploi du mot feature...
Si ça reste comme ça je créerai à part un fichier texte vide en .c avec
l'explorteur de Windows et je l'ajouterait au projet, ça ira plus vite.

*Il ne reviendra pas. Il a disparu parce que toutes les options qui étaient à régler dans le wizard sont maintenant règlables dans les options du projet, ce qui est mieux, parce que ça assure la consistance des #defines entre les différents fichiers.*

Je sais ça. Mais il peut revenir pour les options les plus globales,
comme avant, genre type de calculatrice et les commentaires _nostub justement.
Ensuite pour régler plus précisément l'utilisateur va dans les options du projet.
(Ne le prends pas mal, c'est juste une suggestion... )

*L'option n'est visible que si tu as flashos.a dans ton répertoire Lib. Je le rappelle à chaque fois que j'annonce les releases pourtant... *

Désolé.

Godzil >

[TROLL INUTILE]
*4 -> Le nostub n'est plus, vive le kernel*

C'est pas plutôt l'inverse ?
[/TROLL]

*5 -> Tu ne sais pas utiliser Make*

Ben je pense que la compatibilité avec les fichiers .tpr est préoccupante...
Mais un passage aux Makefiles serait __souhaitable__.

Même quitte à faire une solution mixte avec un .tpr avec des
indications comme quoi on utilise un Makefile. Ca serait possible d'avoir:
--> Compatibilité conservée avec les anciens .tpr
--> Compilation avec Makefiles.


*6 -> Ni gcc en profondeur, et me redit pas "et les asm !" un simple parseur de fichier asm pour detecter les fichiers inclus est ridicule a faire tu peut le faire avec un simple grep..*

Je trouve que ça sort des cordes de tigcc....
Déjà que je trouve qu'il en fait trop parfois...

*Les exemples du .chm pronent l'utilisation des #define USE_TIxxx*
L'aide n'est pas à jour en effet...
De même avec le linker, tous les sujets ne tiennent pas compte
du nouveau linker...
Mais j'ai rien contre le fait de devenir le mainteneur de la doc...

Kevin > J'adore le post 111.

L'aide n'est pas à jour en effet...

je pense qu'on peut difficilement leur tenir rigueur de ne pas avoir la doc à jour, car c'est vraiment un gros truc.

[TROLL INUTILE]
*4 -> Le nostub n'est plus, vive le kernel*

C'est pas plutôt l'inverse ? [/TROLL]

non.
NOstub == sans stub...
le fait est que les programmes prétendument "nostub" de TIGCC ont un stub de plus en plus gros... codes de démarrage, érification de la TI, émulateur 1111, vérification de la ROM, ...
=> le nostub n'existe plus.

bin c'est juste comme le tout premier format de kernel ^^

non.
NOstub == sans stub...
le fait est que les programmes prétendument "nostub" de TIGCC ont un stub de plus en plus gros... codes de démarrage, érification de la TI, émulateur 1111, vérification de la ROM, ... => le nostub n'existe plus.

Oué, je sais. (Et j'ai toujours été contre
tout le code rajouté par TIGCC... )

Mais encore plus contre le kernel

je vois pas ce que vous avez contre le kernel . Quand j'ai fait mon désassembleur, je me suis vraiment rendu compte de toutes les possibilités. Et comme le kernel peut faire tout ce que le nostub peut faire ...

Godzil :
tient un autre truc abérant avec tigcc
Les exemples du .chm pronent l'utilisation des #define USE_TIxxx

C'est parce que les exemples dans le répertoire Examples utilisent ça. Si tu n'aimes pas, envoie un patch.

pourtant avec le fonctionnement actuel de tigcc 0.95 le copier coller d'un code ne fonctionnera PAS (ou générera plein de warning)

Pour les exemples, ça fonctionne parce qu'ils ne définissent aucune calculatrice de destination dans le fichier .tpr (créé avec TIGCC 0.94).

a cause de ces options automatiques (et qui ne devrait PAS etre automatique...)

Si. Ces options sont "automatiques" pour une raison: c'est la seule manière de garantir que tous les fichiers .c sont compilés avec les mêmes options.

Kitsune :
*Alors tu les effaces.*
C'est justement ce qui est embêtant, surtout que je crois
que ça oblige beaucoup de monde à effacer. (Sous-entendu timide: personne ne s'en sert)

C'est bien ça le problème!

*C'est justement le problème: personne ne l'utilise. Nous voulons encourager l'utilisation de cette feature.*
Désolé mais cette fois-ci je ne suis pas d'accord sur l'emploi du mot feature...
Si ça reste comme ça je créerai à part un fichier texte vide en .c avec
l'explorteur de Windows et je l'ajouterait au projet, ça ira plus vite.

Si tout le monde fait ça, je vais faire en sorte qu'il y ait des commentaires par défaut avec plein de pubs pour TIGCC, ça vous convaincra peut-être à mettre vos commentaires à vous.

*Il ne reviendra pas. Il a disparu parce que toutes les options qui étaient à régler dans le wizard sont maintenant règlables dans les options du projet, ce qui est mieux, parce que ça assure la consistance des #defines entre les différents fichiers.*

Je sais ça. Mais il peut revenir pour les options les plus globales,
comme avant, genre type de calculatrice et les commentaires _nostub justement.
Ensuite pour régler plus précisément l'utilisateur va dans les options du projet.
(Ne le prends pas mal, c'est juste une suggestion... )

Tu veux un project wizard, toi? Godzil parlait du template wizard, qui a justement été supprimé parce que ça ne convenait pas du tout pour les options globales!

[TROLL INUTILE]
*4 -> Le nostub n'est plus, vive le kernel*

C'est pas plutôt l'inverse ? [/TROLL]

Si.

*5 -> Tu ne sais pas utiliser Make*

Ben je pense que la compatibilité avec les fichiers .tpr est préoccupante... Mais un passage aux Makefiles serait __souhaitable__.

Pour quoi faire? Ça ne sert à rien...

Même quitte à faire une solution mixte avec un .tpr avec des
indications comme quoi on utilise un Makefile. Ca serait possible d'avoir:
--> Compatibilité conservée avec les anciens .tpr --> Compilation avec Makefiles.

Ça existe déjà. Tu récupères ça (pour respecter la GPL: sources) et tu utilises tigcc -c pour la compilation et tigcc pour le linking.

De même avec le linker, tous les sujets ne tiennent pas compte du nouveau linker...

Lesquels?

squale92
:

[TROLL INUTILE]
*4 -> Le nostub n'est plus, vive le kernel*

C'est pas plutôt l'inverse ? [/TROLL]

non.
NOstub == sans stub...
le fait est que les programmes prétendument "nostub" de TIGCC ont un stub de plus en plus gros... codes de démarrage, érification de la TI, émulateur 1111, vérification de la ROM, ... => le nostub n'existe plus.

Le nouveau linker appelle ça du "TIGCC native" en interne, en effet. Mais le code de démarrage n'est pas un stub (mais bien du code de démarrage), et puis ça reste des programmes qui n'ont pas besoin de kernel. Et le code de démarrage est bien pratique! Contrairement à ce que tu sous-entends là, s'il est bien utilisé, le code de démarrage permet justement de gagner de la place (relogements, BSS, F-Line, ...).

Flanker
: bin c'est juste comme le tout premier format de kernel ^^

Un peu oui, mais c'est mieux fait:
* code de démarrage inclus seulement si nécessaire. Ce n'était pas le cas avec PlusShell 0.99 parce qu'on ne savait pas de quels relogements les DLLs pourraient avoir besoin. Notre solution: Les DLLs sont découragées, et elles n'ont pas le droit d'utiliser des fonctionnalités nécessitant du code de démarrage.
* pas de relogement de RAM_CALLs. Le genre de trucs qui, à part pour CALCULATOR, n'a vraiment rien à faire dans du code de démarrage, surtout en combinaison avec l'autre problème. La solution est d'utiliser les ROM_CALLs qui font les trucs proprement.
* pas de relogement de DLLs dans le code de démarrage. Les DLLs sont découragées, et relogées dans LoadDLL seulement si on les utilise vraiment.

Flanker :
je vois pas ce que vous avez contre le kernel . Quand j'ai fait mon désassembleur, je me suis vraiment rendu compte de toutes les possibilités. Et comme le kernel peut faire tout ce que le nostub peut faire ...

Tu as tout à l'envers. On ne peut même pas faire des TSRs en kernel. Le kernel se mêle de tout ce qui ne le regarde pas. Alors qu'avec TIGCC 0.95, tous les avantages que le kernel avait jadis (BSS, relogements plus compacts, ...) n'existent plus! On peut tout faire en _nostub maintenant.

On ne peut même pas faire des TSRs en kernel.

sisi

La solution est d'utiliser les ROM_CALLs qui font les trucs proprement

donne moi le numéro du ROM_CALL key_down

Les DLLs sont découragées

déconseillées, plutôt que découragées, et c'est quoi l'intérêt d'en faire si c'est pour les déconseiller ?

Flanker
:

La solution est d'utiliser les ROM_CALLs qui font les trucs proprement

donne moi le numéro du ROM_CALL key_down

Ces constantes là peuvent être exprimées facilement en termes de CALCULATOR: CALCULATOR?344:340.

Les DLLs sont découragées

déconseillées, plutôt que découragées, et c'est quoi l'intérêt d'en faire si c'est pour les déconseiller ?

Il y a un et un seul usage supporté, c'est pour dépasser la limite de 64 KO.

CALCULATOR: CALCULATOR?344:340

ça prend plus de place

Mais le code de démarrage n'est pas un stub (mais bien du code de démarrage)

un en-t^te gigantesque c'est...
dans le temps, certains reprochainet aux programmes en mode kernels leurs en-têtes... mais finalement, en mode"nostub", doit y en avoir plus, avec les options par défaut...

et puis ça reste des programmes qui n'ont pas besoin de kernel.

oué...
disons des programmes no-kernel,alors, et pas no-stub

Contrairement à ce que tu sous-entends là, s'il est bien utilisé, le code de démarrage permet justement de gagner de la place

entre mettre ce code une fois dans chaque programme => 20 fois sur la machine
ou une seule fois dans un kernel,
je choisirais le kernel, si y'avait le choix...

Déconseillées, plutôt que découragées, et c'est quoi l'intérêt d'en faire si c'est pour les déconseiller ?

L'interet c'est de dépasser les 64Ko mais je trouve quand même bête de faire des features qui ne sont pas conseillés

*entre mettre ce code une fois dans chaque programme => 20 fois sur la machine
ou une seule fois dans un kernel,
je choisirais le kernel, si y'avait le choix... *

Je suis d'accord là-dessus, mais le kernel aussi a ses défauts...
Certains kernels ( ) ont tendance à avoir des machins
nommés par exemple "Protection anti-crash" ou bien
"Exécution de toutes les commandes TI-Basic dans une fonction",
qui ne marchent jamais et occuppent de la RAM pour rien.

De plus ça amène à choisir un format personnalisé, et je suis contre.
Je veux soit le format standard (donc tigcc native)
soit un format déjà connu, indépendamment de toute plate-forme.

(a.out, COFF, ELF...)

Protection anti-crash

ça marche très bien chez moi

soit un format déjà connu, indépendamment de toute plate-forme.
(a.out, COFF, ELF...)

ça, c'est totalement inutile, par contre, sauf si tu fais un programme qui n'utilise aucun ROM_CALL ni aucune autre particularité de la TI

standard (donc tigcc native)

en quoi il est standard ?

Certains kernels ( ) ont tendance à avoir des machins nommés par exemple "Protection anti-crash"

bah, suffit de bien choisir son kernel...
perso, preOS m'a pas mal servi, pour ça, qd je codais avec AS...

De plus ça amène à choisir un format personnalisé, et je suis contre. Je veux soit le format standard

en même temps, pdt bien longtemps, le format kernel était le format "standard"...
et les commentaires nostub, par exemple, c'est pas un format personalisé ?

*ça marche très bien chez moi *
Ben pas chez tout le monde
(notamment avec l'AMS 2.07+)

*ça, c'est totalement inutile, par contre, sauf si tu fais un programme qui n'utilise aucun ROM_CALL ni aucune autre particularité de la TI *
Non, par exemple avec le a.out le programme peut utiliser des libs dynamiques
et des sections BSS.
(ce qui est le seul truc vraiment bien du kernel, le reste n'étant que des
tricheries, comme par exemple même le BSS ça se fait très bien par un HeapAllocPtr
et les RAM Calls j'en ai jamais eu besoin.)

(Le seul truc pouvant être utile
c'est les fonctions de clavier)

Et si on veut aller plus loin pour permettre plus de trucs différent,
genre les RAM Calls et encore plus de trucs que ce que le format kernel
peut gérer, ben y'a qu'à utiliser COFF ou ELF.

*en quoi il est standard ?*
Parceque c'est le format que la TI reconnaît sans
un hack genre << "preos()", ENTER >>, et qui est
utilisé pour les RAM apps de TI Flash Studio.

(Donc oué pas "standard" mais "officiel")

"et les commentaires nostub, par exemple, c'est pas un format personalisé ?"

Oui.
(Donc je suis contre )

Bon je suis à la limite d'accord qu'il y ait un wrapper
pour les progs ou un lanceur + ExePack...

Mais seulement parceque ça apporte quelquechose...
En l'occurrence pour l'ExePack, plus de 24 Ko par prog.

Ensuite vous allez me dire le kernel le permet aussi,
je dis ben l'ExePack compresse.

Ensuite on me dira "ben y'a qu'à faire du kernel avec ExePack, ça marche"
Et je répondrai y'a besoin de lancer un kernel d'abord,
qui contient toujours des fonctions inutiles dont je ne me
sers pas. (Alors que sous TIGCC bien que ce soit pas du pur
natif généralement, ben il me laisse le choix sur pas mal de
choses cf les options de projet)

Enfin bon... les DLLs je suis pour, mais ça fait lourd dans un prog
nostub... (enfin nokernel )

Donc c'est pour ça que je voudrais un kernel LEGER qui reloge
un format comme a.out, COFF ou ELF et qui ne fasse qu'allouer
le BSS (puisque son support est inclut dans ces formats),
faire la liaison dynamique et puis c'est tout.

Pour le reste, on se débrouille très bien sans RAM Call et les
programmes nostub n'ont pas besoin de protection anti-crash,
car en général une fois finis ils ne plantent pas.
(Et s'ils ne sont pas finis, ben y'a VTI, et même si on est sous
AS par exemple, ben on a qu'à être prêt à ce que la caltos plante,
en ayant tout archivé, point)

les
programmes nostub n'ont pas besoin de protection anti-crash, car en général une fois finis ils ne plantent pas.

hum...
que ça soit kernel ou nostub, si y'a pas de bug, ça plante pas...
mais que ce soit nostub ou kernel, si c mal codé et plein de failles, ça plantera...

139>

la protection anti-crash n'est pas inhérente au kernel . Tu peux très bien la supprimer.

La protection anticrash me sert assez souvent, et me permet de débugguer à tout moment (vu que preos me lance un désassembleur quand un crash est intercepté) . J'ai des programmes non finis qui plantent suffisament rarement pour être utilisables.

Parceque c'est le format que la TI reconnaît sans
un hack genre << "preos()", ENTER >>, et qui est utilisé pour les RAM apps de TI Flash Studio.

bah si tu veux pas faire de hack, tu n'as pas intérêt à faire des programmes de 24ko ...
et si t'aimes bien ttstart, il est super facile de faire un lanceur de programme kernel du genre preos("prgmname")

Non, par exemple avec le a.out le programme peut utiliser des libs dynamiques et des sections BSS.

Pour tes formats ELF & Cie, ça sert strictement à rien. Si tu dois faire des libs dynamique pour chaque appel de rom_call, ton hello world va faire 50ko. De toute façon, les progs sur TI ne sont portables, autant avoir un format adapté !

Ben dans ce cas, puisque ça revient au même, on se
retrouve avec du code inutile dans le cas du kernel ^^
Le programmeur n'a qu'à faire gaffe.

Surtout que la protection anti-crash revient généralement à
éviter un crash façon Adress Error pour retourner sur Home.
Mais le programme a laissé plein de traces, et dans presque
tous les cas:

- Bugs genre le VAR-LINK ne s'ouvre plus,
la mémoire dite System est monté en flèche genre 90 000 à 160 000 octets, aucun programme ne peut plus être lancé depuis l'invite Home,
ou on est coincé sur Home et on ne peut plus rien ouvrir d'autre...
- PreOS a changé un flag et on ne peut plus relancer le
programme, sinon une erreur disant que c'est en cours d'utilisation.

Donc on a plus qu'à faire (sur une 92+) un petit
F5, [Diamant] + '(', 'cos', '2', puis [ON],
autrement dit un Reset RAM...
Ce qui revient au même que l'Adress Error du nostub
(qui en passant nous en disait plus sur comment le
programme avait planté --> pb d'adresse impaire)

Donc ça fait du code inutile et c'est carrément moins bien
pour le programmeur

Écoute, si on accuse le mainteneur d'un portage de GCC de ne pas bien connaître GCC, c'est quand-même le prendre un peu pour un c*n, tu ne trouves pas?

Si si , il trouve, mais il ne le dit pas.

Quand à l'appel de ROM Call que toute histoire de lib dynamique
aille se faire mettre: faire comme le NoStub, donc comme ça:
(Je le mets en assembleur GNU, parcequeuuuuuuu !!!)

move.l $C8,%a5
move.l NB_ROM_CALL*4(%a5),%a0
| Passage des arguments
jbsr (%a0)
| éventuel add.w #(taille),a7
| ou bien lea.

Le programmeur n'a qu'à faire gaffe.

t'as fait combien de gros programme en asm qui ne soient pas buggués ?

bah chez moi, s'il y a un crash : j'ai d'abord une fenêtre avec un désassembleur/éditeur hexa qui s'affiche, avec l'endroit du crash et la valeur des registres, c'est beaucoup plus pratique pour débugguer que VTI quand on peut pas tracer le programme ou quand le bug est aléatoire.
Ensuite, le point _exit permet au programme lancé de nettoyer ses propres variables
Enfin, preos me permet de retourner au home et de là, j'efface les handles perdus à la main, s'il y en a eu.

Et je vois pas en quoi c'est carrément moins bien pour le programmeur ?
Et si tu l'aimes si peu, bin tu la supprimes, c'est pas dur

Kitsune :
Quand à l'appel de ROM Call que toute histoire de lib dynamique
aille se faire mettre: faire comme le NoStub, donc comme ça:
(Je le mets en assembleur GNU, parcequeuuuuuuu !!!)

move.l $C8,%a5
move.l NB_ROM_CALL*4(%a5),%a0
| Passage des arguments
jbsr (%a0)
| éventuel add.w #(taille),a7 | ou bien lea.

tu veux m'apprendre à appeler un ROM_CALL en asm ?
ton $C8, tu crois qu'il est commun à toutes les plate formes basées sur un 68000 ?

En passant, pas besoin de kernel pour avoir un exit.

#ifdef DEBUG
SetIntVec(.... // Mettre tous les pointeurs voulus à 'exit'.

DEFINE_INT_HANDLER (exit)
{
// ...
}
#endif

sauf que là, la kernel essaie d'avoir un état le plus stable possible, pas ton truc

Flanker
:

CALCULATOR: CALCULATOR?344:340

ça prend plus de place

Pas forcément. Un relogement, ça prend de la place aussi.

squale92
:

Mais le code de démarrage n'est pas un stub (mais bien du code de démarrage)

un en-t^te gigantesque c'est... dans le temps, certains reprochainet aux programmes en mode kernels leurs en-têtes... mais finalement, en mode"nostub", doit y en avoir plus, avec les options par défaut...

Non. Déjà n'oublie pas que les trucs du style vérification du modèle sont rajoutés aussi en kernel, et puis c'est court, tout ça. Et en plus, comme déjà dit, les entêtes rajoutés le sont souvent pour gagner de la place.

Contrairement à ce que tu sous-entends là, s'il est bien utilisé, le code de démarrage permet justement de gagner de la place

entre mettre ce code une fois dans chaque programme => 20 fois sur la machine
ou une seule fois dans un kernel, je choisirais le kernel, si y'avait le choix...

Si tu ne mets pas ce code dans le programme, tu dois mettre des informations qui indiquent au kernel que tu veux que ce code soit exécuté, qui prennent presque autant (voire plus dans certains cas) de place. (Compare CALCULATOR: notre solution _nostub: adressage PC-relatif, aucun relogement nécessaire; solution kernel: un relogement pour chaque utilisation. Qu'est-ce qui est plus économique en place (question rhétorique)?) Et puis le kernel lui-même prend une place énorme par rapport à notre petit code de démarrage!

Uther
:

Déconseillées, plutôt que découragées, et c'est quoi l'intérêt d'en faire si c'est pour les déconseiller ?

L'interet c'est de dépasser les 64Ko mais je trouve quand même bête de faire des features qui ne sont pas conseillés

C'est conseillé si et seulement si on a le problème que c'est censé résoudre (la limite de 64 KO). Toute autre utilisation est un abus.

Kitsune :
De plus ça amène à choisir un format personnalisé, et je suis contre.
Je veux soit le format standard (donc tigcc native)
soit un format déjà connu, indépendamment de toute plate-forme.
(a.out, COFF, ELF...)

Et moi, je veux que ce soit le format natif de la plateforme (AMS).

Flanker
:

standard (donc tigcc native)

en quoi il est standard ?

Parce que c'est:
1. le format natif de l'outil de développement standard de facto et
2. le format natif de la plateforme (AMS).

squale92
:

De plus ça amène à choisir un format personnalisé, et je suis contre. Je veux soit le format standard

en même temps, pdt bien longtemps, le format kernel était le format "standard"...

Non, c'était toujours un format non-standard collé par dessus le format natif.

et les commentaires nostub, par exemple, c'est pas un format personalisé ?

C'est une convention qui permet à des shells et programmes semblables de trouver certaines informations de manière fiable. Mais les programmes peuvent très bien s'exécuter sans rien connaître de ce format (AMS les lance sans problèmes), donc ce n'est pas un format à part.

Kitsune :
(Le seul truc pouvant être utile c'est les fonctions de clavier)

OSdequeue est plus propre pour ça.

Kitsune :
Bon je suis à la limite d'accord qu'il y ait un wrapper pour les progs ou un lanceur + ExePack...

Au passage, ExePack sera peut-être bientôt remplacé par LZMA. (Je compte le faire, donc si Sebastian ne le bloque pas, ce sera fait.)

Mais seulement parceque ça apporte quelquechose... En l'occurrence pour l'ExePack, plus de 24 Ko par prog.

LZMA compresse encore mieux.

Enfin bon... les DLLs je suis pour, mais ça fait lourd dans un prog
nostub... (enfin nokernel )

Moi, je suis contre.

squale92
:

les
programmes nostub n'ont pas besoin de protection anti-crash, car en général une fois finis ils ne plantent pas.

hum...
que ça soit kernel ou nostub, si y'a pas de bug, ça plante pas... mais que ce soit nostub ou kernel, si c mal codé et plein de failles, ça plantera...

C'est vrai en théorie, mais pas en pratique...

Flanker
: et si t'aimes bien ttstart, il est super facile de faire un lanceur de programme kernel du genre preos("prgmname")

Ça existe déjà: titanik("prgmname"). Mais tel quel, ça ne marche que sur TI-89 Titanium.

Pour tes formats ELF & Cie, ça sert strictement à rien. Si tu dois faire des libs dynamique pour chaque appel de rom_call, ton hello world va faire 50ko. De toute façon, les progs sur TI ne sont portables, autant avoir un format adapté !

Pour les ROM_CALLs, il y a la F-Line! On ne peut pas plus compact! Je ne comprends pas toute cette obsession pour les relogements de ROM_CALLs. Même OPTIMIZE_ROM_CALLS est plus compact que les ROM_CALLs par relogements.

Kitsune :
Ce qui revient au même que l'Adress Error du nostub
(qui en passant nous en disait plus sur comment le programme avait planté --> pb d'adresse impaire)

En effet, je trouve que le fait de n'afficher même pas le type d'erreur est un mauvais choix de la part de PreOs...

En effet, je trouve que le fait de n'afficher même pas le type d'erreur est un mauvais choix de la part de PreOs...

je pense comme PpHd, ça ne sert à rien d'avoir juste Adress Error. Si tu veux plus, tu peux utiliser mon PreOS modifié (mais uniquement sur 92+)

Pour les ROM_CALLs, il y a la F-Line! On ne peut pas plus compact! Je ne comprends pas toute cette obsession pour les relogements de ROM_CALLs. Même OPTIMIZE_ROM_CALLS est plus compact que les ROM_CALLs par relogements.

t'as pas compris le pb, je disais que les ROM_CALL étaient spécifiques à la TI, donc qu'ils soient utilisés en F-Line, en kernel ou autrement, ça ne change rien.