TIGCC 0.95 Beta 8 - Page 6

Flanker
: J'ai des programmes non finis qui plantent suffisament rarement pour être utilisables.

Un programme qui plante, aussi rarement que ce soit, n'est pas utilisable! La stabilité est nettement plus importante que de gagner quelques octets par ci par là.

Flanker
:

Le programmeur n'a qu'à faire gaffe.

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

Regarde les miens...
Avec un peu de discipline (c'est-à-dire ne pas optimiser tout ce qui est optimisable, mais utiliser le maximum de ROM_CALLs, se servir de macros comme ROM_CALL etc.), c'est tout à fait faisable.

Ensuite, le point _exit permet au programme lancé de nettoyer ses propres variables

Ou de rendre le système encore plus instable.

Enfin, preos me permet de retourner au home et de là, j'efface les handles perdus à la main, s'il y en a eu.

Mauvaise idée. La seule manière fiable de réagir à un plantage, récupéré ou pas, est un reset. Sinon, ça peut planter à nouveau à tout moment (parce que n'importe quel contenu en RAM peut avoir été corrompu). Donc l'anticrash ne sert à rien. Je ne comprends pas trop pourquoi vous voulez éviter les resets à tout prix, un reset n'a rien de méchant depuis qu'il y a la récupération de l'archive.

Et je vois pas en quoi c'est carrément moins bien pour le programmeur ?

Parce que ça encourage la programmation sale et peu fiable, à travers le message: "De toute façon, le kernel récupèrera ton plantage."

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!

faut faire comme moi un seul appel au RAM_CALL et après que du PC-relatif !

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

les programmes kernel sont en général plus vieux donc codés en ASM pour une calc beaucoup moins bien connue que maintenant. Ca n'a strictement rien à voir avec kernel/nostub !

Flanker
:

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.

Si tu utilises la F-Line pour les ROM_CALLs, tu n'as pas besoin de prévoir des relogements non-standard (donc qui ne sont pas dans ELF et compagnie) dans ton format. C'est ça que ça change.

Regarde les miens...

j'ai dit GROS, pas un prog de 2ko !

Avec un peu de discipline (c'est-à-dire ne pas optimiser tout ce qui est optimisable, mais utiliser le maximum de ROM_CALLs, se servir de macros comme ROM_CALL etc.), c'est tout à fait faisable.

je m'en suis rendu compte, que tu n'optimisais pas tout ce qui était optimisable
lr problème reste qu'avec un gros programme avec des hacks indispensables à certaines fonctions, bah c'est beaucoup plus dur à débugguer.

Un programme qui plante, aussi rarement que ce soit, n'est pas utilisable!

Flanker
:

Regarde les miens...

j'ai dit GROS, pas un prog de 2ko !

Tu veux que je les rende plus gros? C'est facilement faisable.

Pour en revenir au sujet, je viens de voir "Save by move optimization" ? ça veut dire quoi ?
et comment on supprime l'optimisation éSave by range cuttingé ?

Flanker
: Pour en revenir au sujet, je viens de voir "Save by move optimization" ? ça veut dire quoi ?

Optimisation move toto,... -> move toto(PC),... ou lea toto,... -> lea toto(PC),....

et comment on supprime l'optimisation éSave by range cuttingé ?

Dans les options.
Et pourquoi veux-tu le faire?! Si le linker fait ces optimisations, ce n'est pas pour les chiens! Ces optimisations sont utiles même en assembleur (surtout si on code proprement, c'est-à-dire avec des fichiers .asm compilés séparément, pas avec tout inclus en un seul).

ah bah je me suis planté alors, c'est le move optimization que je veux supprimer. Sur le moment, j'ai cru qu'il s'agissait d'organiser le code pour permettre des bra.s au lieu de bra.w ou des bra.w au lieu de jmp

Déjà n'oublie pas que les trucs du style vérification du modèle sont rajoutés aussi en kernel

c'est pas inclut au kernel, le code de vérification ?
argh, si c pas le cas, c mal fait

Et puis le kernel lui-même prend une place énorme par rapport à notre petit code de démarrage!

le kernel n'est pas dupliqué, et inclut des fonctionnalités supplémentaires

[cite] Non, c'était toujours un format non-standard collé par dessus le format natif. [:cite]
enfin, en même temps, le format "natif" n'existait pas, à l'époque

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

bah, je sais pas, mais le mode kernel ne fait pa splus planter, y'a pas de raison, c'est ridicule...
un programme qui bug, tu le compile en nostub ou en kernel, il plantera toujours autant... ou alors, y'a une couille dans le compilo

je pense comme PpHd, ça ne sert à rien d'avoir juste Adress Error

perso, ça aide, qd tu code, de savoir quel type d'erreur ça fait...
(genre, l'address error est assez explicite...)
mais bon, suffit d'utiliser l'outils fourni avec preOS pour lancer le prog...

La seule manière fiable de réagir à un plantage, récupéré ou pas, est un reset. Sinon, ça peut planter à nouveau à tout moment (parce que n'importe quel contenu en RAM peut avoir été corrompu). Donc l'anticrash ne sert à rien.

a sauver des données non sauvées
(par exemple, archiver/désarchiver un fichier source ASM on-calc, c la galère)
à voir les circonstances du plantage et obtenir des infos permettant de trouver sa cause

les programmes kernel sont en général plus vieux donc codés en ASM pour une calc beaucoup moins bien connue que maintenant. Ca n'a strictement rien à voir avec kernel/nostub !

exactement

Flanker :
ah bah je me suis planté alors, c'est le move optimization que je veux supprimer. Sur le moment, j'ai cru qu'il s'agissait d'organiser le code pour permettre des bra.s au lieu de bra.w ou des bra.w au lieu de jmp

Ça, ça sera fait avec --reorder-sections dès la prochaine bêta, mais il faut que tu organises ton code en sections pour que ça puisse fonctionner (on ne coupe pas les sections en morceaux).

ça, tu peux être sûr que je ne l'utiliserais jamais Je n'organise pas mon code n'importe comment, et je n'ai pas envie qu'un compilo vienne mettre le nez dans mes affaires

squale92
:

Déjà n'oublie pas que les trucs du style vérification du modèle sont rajoutés aussi en kernel

c'est pas inclut au kernel, le code de vérification ?

Ça dépend du kernel.

Et puis le kernel lui-même prend une place énorme par rapport à notre petit code de démarrage!

le kernel n'est pas dupliqué,

Même en le "dupliquant", notre code de démarrage est plus petit.

et inclut des fonctionnalités supplémentaires

Lesquelles? On a tout: relogements compacts (et même compressés), ROM_CALLs par relogement, sections BSS, détection du modèle, ...

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

enfin, en même temps, le format "natif" n'existait pas, à l'époque

Tu veux dire à l'époque de Fargo? Parce que depuis l'introduction du module Plus, il y a un format natif, et les kernels sont obsolètes.

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

bah, je sais pas, mais le mode kernel ne fait pa splus planter, y'a pas de raison, c'est ridicule...
un programme qui bug, tu le compile en nostub ou en kernel, il plantera toujours autant... ou alors, y'a une couille dans le compilo

Oui, mais tout ça, c'est de la théorie. La pratique est que les programmes qui boguent le plus sont en kernel.

La seule manière fiable de réagir à un plantage, récupéré ou pas, est un reset. Sinon, ça peut planter à nouveau à tout moment (parce que n'importe quel contenu en RAM peut avoir été corrompu). Donc l'anticrash ne sert à rien.

a sauver des données non sauvées

Si on n'a pas archivé ses données, c'est déjà une erreur.

(par exemple, archiver/désarchiver un fichier source ASM on-calc, c la galère)

Moi, quand je code on-calc (même pour le BASIC!), c'est:
CopyVar program,backup
Archive backup
UnArchiv program
éditer le programme
Archive program
UnArchiv backup
DelVar backup
program()

à voir les circonstances du plantage et obtenir des infos permettant de trouver sa cause

Pour ça, on utilise un débogueur (DB92 par exemple).

à voir les circonstances du plantage et obtenir des infos permettant de trouver sa cause

et quand il n'y a pas de plantage quand il est lancé par db92 ? sisi, ça m'est arrivé.
mais bon, maintenant, j'ai ma version perso de PreOS avec désassembleur et état des registres en cas de plantage

Oui, mais tout ça, c'est de la théorie. La pratique est que les programmes qui boguent le plus sont en kernel.

pffffff tu ferais un bon commercial, à manipuler les phrases comme ça. Les programmes qui boguent le plus sont les vieux programmes en assembleur.

CopyVar program,backup
Archive backup
UnArchiv program
éditer le programme
Archive program
UnArchiv backup
DelVar backup program()

y a mieux, une simple fonction archive/unarchive, en cas de plantage on récupère dans la corbeille , ou encore plus récent, tu fais ENTER quand l'éditeur te demande si tu veux enregister le texte quand tu quittes (TSR powaaa)

Même en le "dupliquant", notre code de démarrage est plus petit.

ça dépend de combien de fois on le duplique

Lesquelles? On a tout: relogements compacts (et même compressés), ROM_CALLs par relogement, sections BSS, détection du modèle, ...

à quand l'anticrash dans le stub du nostub ?

Tu veux dire à l'époque de Fargo? Parce que depuis l'introduction du module Plus, il y a un format natif, et les kernels sont obsolètes.

et bien, Fargo est quand même la base du développement sur machines 68k...
et après, y'a fallu pas mal de temps pour qu'on puisse faire des progs corrects en nostub... surtout qui permettent autant de chose qu'en mode kernel...

La pratique est que les programmes qui boguent le plus sont en kernel.

peut-être parce qu'ils sont plus vieux, et que la machine était moins connue à l'époque, non ?
et puis, en regardant sur ticalc combien de prog kernel plantent et combien de progs nostub plantent, je pense que le nostub l'emporte

Moi, quand je code on-calc (même pour le BASIC!), c'est:
CopyVar program,backup
Archive backup
UnArchiv program
éditer le programme
Archive program
UnArchiv backup
DelVar backup program()

j'ai pas la patience...

Pour ça, on utilise un débogueur (DB92 par exemple).

bof... c'est moins lourd d'avoir un kernel

Kevin Kofler
:

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.

Mais non, pas besoin d'employer ces méthodes dictatoriales, il faut juste laisser ce truc s'installer. Moi, je viens de mettre à jour punkoe pour qu'il utilise les commentaires _nosub, car je trouve que ces commentaires sont une très bonne idée.

serioussam
:

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

Alors toi, tu sers à rien d'autre qu'à jeter de l'huile sur le feu... tu vas finir dehors si tu continues ce genre de post inutile...

Pour info, j'ai pas eu accès au net depuis 24h, j'aurais été bien en mal de répondre ...

Et non, je ne trouve pas, sinon je n'aurais pas fait la remarque, mon opinion est que puisque ça a tendance à se vérifier, la remarque était peut être justifiée

Tiens une auter abération de tigcc-ide..

les raccourcis...

Microsoft, pour windows (copiant apple) a décrété que les copier coller ce ferrait avec les touches CTRL+C pour copier, CTRL+V pour coller, CTRL+X pour couper et CTRL+Z pour annuler (et accesoirement CTRL+Y pour désanuler)

et qu'est-ce qu'on retrouve sous TIGCC-IDE ?

Des raccourci clavier de merdes datant d'application dos préhistoriques..

a savoir :
Annuler : alt+backspace
désAnnuler : alt+Shift+backspace
Couper : Shift+Del
Copier : Control+Ins
Coller : Shift+Ins

Quelle belle ignominie...

Déja que l'ide a ces gros soucis en matiere d'usabilité alors ça sa tue completement l'usabilité.. Je comprend largement ceux qui preferent utiliser des IDE plus généraux pour programer avec tigcc..

Encore un troll totalement infondé de monsieur Godzil:
* Cher monsieur Godzil, TIGCC IDE comprend tout aussi bien les raccourcis avec les touches dédiées (ceux que tu critiques) et les raccourcis avec les lettres (ceux que tu demandes). Toute application qui se respecte gère les 2, d'ailleurs. Après, ce qu'on affiche dans le menu est purement une question de goût.
* Personnellement, j'utilise Ctrl+Z et Ctrl+Y (parce que Alt+BkSp n'est pas géré par toutes les apps, pour des raisons de paresse du programmeur, je suppose, vu que c'est une combinaison nettement plus logique), mais jamais Ctrl+C/V/X (bon, à part dans l'éditeur merdique de Qt Designer qui ne comprend pas les vraies combines). Ctrl+C/V/X sont une abomination. Ctrl+Ins, Shift+Del, Shift+Ins sont beaucoup plus pratiques.

...

Ctrl+v/x/c marche d'un maniere abominablement erratique avec tigccide.. Genre je me retrouve avec un ctrl+c &ctrl+v qui m'affiche

-------------------------------------------------------
-------------------------------------------------------
Le fichier truc a été modifié, voulez vous le recharger

Oui - Non
------------------------------------------------------- -------------------------------------------------------

Super hein le copier coller !

shift/alt/truc est tout sauf fonctionel, en plus toi qui prone d'utiliser les trucs standard...

Godzil :
...

Ctrl+v/x/c marche d'un maniere abominablement erratique avec tigccide.. Genre je me retrouve avec un ctrl+c &ctrl+v qui m'affiche

-------------------------------------------------------
-------------------------------------------------------
Le fichier truc a été modifié, voulez vous le recharger

Oui - Non
------------------------------------------------------- -------------------------------------------------------

Je n'ai pas ce bogue, si tu l'as, merci de remplir le formulaire de Bug Report avec des instructions précises permettant de le reproduire.

shift/alt/truc est tout sauf fonctionel,

en plus toi qui prone d'utiliser les trucs standard...

Les trucs standard (convention SAA), c'est Shift+Ins et compagnie. Les autres, c'est une invention de Window$.

Kevin Kofler
: Ctrl+C/V/X sont une abomination. Ctrl+Ins, Shift+Del, Shift+Ins sont beaucoup plus pratiques.

Et la marmotte...
[sondage=14449]

Kevin Kofler
:

-------------------------------------------------------
-------------------------------------------------------
Le fichier truc a été modifié, voulez vous le recharger

Oui - Non
------------------------------------------------------- -------------------------------------------------------

Je n'ai pas ce bogue, si tu l'as, merci de remplir le formulaire de Bug Report avec des instructions précises permettant de le reproduire.

Dur a reproduire (ce produit tjrs quand on veux pas qu'il se produise..)

[cite]

en plus toi qui prone d'utiliser les trucs standard...

Les trucs standard (convention SAA), c'est Shift+Ins et compagnie. Les autres, c'est une invention de Window$.

Pour ta culture, les raccourcis meta+C, meta+V, meta+X, meta+Z et meta+Y on été a la base mis en place par Apple dans leur systeme d'exploitation du macintosh. Microsoft dans leur vielle application DOS utilisait le system shift machin & co.
Quand windows 95 est apparu (avec son lots de piquage d'idée a droite a gauche) microsoft c'est rendu compte que les raccourci du mac etait BCP plus pratique et on donc pronné l'utilisation de ces raccourcis avec la couthe CTRL plutot que la touche ALT (sur MacOS la touche utilisé est Command (celle avec la pomme dessus), pas Option, ni Ctrl)

Bref

meta+C, meta+V, meta+X, meta+Z et meta+Y est le standard de facto pour TOUT les OS/applications sérieuses et digne de ce nom


edit: pbm avec le premier cite

han, Kevin prône des standards obsolètes !

-> poubelle direct le standard obsolète ©

Ctrl+C/V/X sont une abomination.
Les trucs standard (convention SAA), c'est Shift+Ins et compagnie

alors, AMS ne respecte pas les standards
=> on ne peut pas considérer AMS comme un standard
=> Kernel powa

le topic dévie !

bah si l'auteur arrêtait de dire n'importe quoi aussi
après quoiqu'il arrive c'est sur moi que ça va crier de toutes façons ...

pauvre petit Ximoon martyrisé
viens dans mes bras, que je te console

hmmm restons en là svp

huhu