TI-GCC Format des fichiers .a - Page 2

[avis personnel qui ne demande qu'à être réfuté par l'intéressé]Tu sais, moi ça ne me suprendrait pas qu'il frôle l'extrême-droite... j'ai pas mal d'indices pour le penser en tout cas il y a certains points de sa mentalité que je trouve très malsains...[/avis personnel qui ne demande qu'à être réfuté par l'intéressé]

Je préfèrerais ça que l'extrême gauche

les deux sont aussi pire l'un que que l'autre !

Non, l'extrême gauche est pire (à mon humble avis) ...
De toutes façons à choisir entre la peste et le choléra ...

Mais ne dissertons pas de cela ici, cela n'a pas lieu d'être

Oué il vaut mieux stopper maintenant ... l'état du forum risquerait d'être comparable assez rapidement à une certaine ville du Japon à la fin de la seconde guerre mondiale

Thibaut> je n'irai qd même pas jusque là
enfin, chacun est libre de croire ce qu'il veut.

Thibaut> sans le savoir, tu dois bien cotyer des gens qui sont pour l'extrème droite !
rappeles-toi des pourcentages aux élections... avec ça, il est certain que chacun d'entre nous connaisse des gens qui ont voté extréme droite...
dans mon village, que ce soit aux présidentielles ou aux législatives, il y a eu 30% pr l'extrème droite... alors que cun village tranquille... c triste.

Kevin: Peut etre, mais seuls les progs kernels seront utilisables sur PreRom

PpHd a écrit :
Kevin: Peut etre, mais seuls les progs kernels seront utilisables sur PreRom

PreRom?! Le fait de parler de Pollux t'a t'il fait envie d'annoncer des projets à la GTools???
Et tu sais très bien que si les programmes _nostub ne marchent pas, les programmes kernel utilisant les mêmes ROM_CALLs ne marcheront pas non plus.

Thibaut a écrit :
[avis personnel qui ne demande qu'à être réfuté par l'intéressé]Tu sais, moi ça ne me suprendrait pas qu'il frôle l'extrême-droite... j'ai pas mal d'indices pour le penser en tout cas il y a certains points de sa mentalité que je trouve très malsains...[/avis personnel qui ne demande qu'à être réfuté par l'intéressé]

Non seulement c'est totalement hors-sujet, c'est aussi totalement faux. Je ne suis pas du tout pour l'extrême-droite! J'ai même été aux grandes manifestations anti-Haider ici en Autriche. Ceci dit, je n'ai pas envie de parler de politique dans ce topic, et si je viens de le faire, ce n'est que parce que tu m'as attaqué personnellement.

Thibaut, mais la en veilleuse ça vaut mieux.
Ce que tu fais c'est ni plus ni moins que des calomnies.
De plus, je crois que les français sont mal placés pour parler.
J'en profite pour rajouter que tes metaphores avec le Japon sont franchement mal choisis (je reste poli).

Kevin : pardon

>Kevin: PreRom?! Le fait de parler de Pollux t'a t'il fait envie d'annoncer des projets à la GTools???
Ben j'ai deja commencer a coder. Le boot, le trap #4, l'int 6 sont deja ecrits. Il me manque l'int 1 et 6, le link et la gestion des handles, mais je sais comment les coder. Pas mal pour un projet fantome

>Et tu sais très bien que si les programmes _nostub ne marchent pas, les programmes kernel utilisant les mêmes ROM_CALLs ne marcheront pas non plus.
Ce n'est pas pour ca. En Kernel, on peut savoir AVANT l'execution du programme si les rom calls sont disponibles. Pas en nostub. Voila pourquoi les progs nostub ne marcheront pas (Du moins pas de maniere saine, puisque seule une partie des rom calls seront disponibles).

PpHd a écrit :
>Et tu sais très bien que si les programmes _nostub ne marchent pas, les programmes kernel utilisant les mêmes ROM_CALLs ne marcheront pas non plus. Ce n'est pas pour ca. En Kernel, on peut savoir AVANT l'execution du programme si les rom calls sont disponibles. Pas en nostub. Voila pourquoi les progs nostub ne marcheront pas (Du moins pas de maniere saine, puisque seule une partie des rom calls seront disponibles).

N'importe quoi. Si c'est implémenté correctement (pas difficile), la seule différence est que le programme _nostub ne donnera une erreur que quand le ROM_CALL inexistant est appelé (tu crées une fonction qui ne fait que donner une erreur "ROM resident routine not available" et tu mets son adresse à la place de tous les ROM_CALLs non implémentés) et pas au moment de l'exécution. Ne trouve pas des excuses bidon pour le fait que tu es trop paresseux pour implémenter la table en $c8.

Certains programme peuvent ne pas supporter etre interrompus n'importe quand ! J'y ai eflechis avant de faire ca quand meme.

Il vaut mieux que certains programmes marchent, d'autres donnent un message d'erreur, et quelques rares plantent plutôt que qu'aucun programme ne marche.

j'ai du rater qqc...
c quoi PreRom ?

Good question

> squale92 :
Un projet de ROM qu'a débuté PpHd

PreOS
PreRom

héhé sacré PrépréHd ! (cherchez le jeu de mot nul)

c'est donc ce que je pensais...
sauf que je pensais pas que quelqu'un se remettrait un jour à un tel projet

>Kevin: Il vaut mieux que certains programmes marchent, d'autres donnent un message d'erreur, et quelques rares plantent plutôt que qu'aucun programme ne marche.

Avec ca on est obbligé de tester tous les programmes dans toutes les configs pour tester toutes les rom_calls. C'est chiant. Et les variables systemes ? Non, c'est vraiment plus sain de n'autoriser que les programmes kernels.

PpHd a écrit :
>Kevin: Il vaut mieux que certains programmes marchent, d'autres donnent un message d'erreur, et quelques rares plantent plutôt que qu'aucun programme ne marche.
Avec ca on est obbligé de tester tous les programmes dans toutes les configs pour tester toutes les rom_calls. C'est chiant.

Tu n'es pas obligé de tester quoi que ce soit! Tu dis juste que c'est supporté en théorie, mais que les programmes peuvent planter.

Et les variables systemes ?

Si elles ne sont pas supportées, tu les pointe vers un endroit qui est totalement ignoré et tu le mets à 0 avant de lancer les programmes _nostub.

Non, c'est vraiment plus sain de n'autoriser que les programmes kernels.

C'est une tentative de chantage, ça!
Bon, si ta PreRom sort vraiment et si des gens sont suffisamment bêtes pour l'utiliser, quelqu'un (moi?) compilera ttstart en kernel. Ça permettra d'utiliser les programmes _nostub.
Et pour la table en $c8, tu seras bien obligé de la mettre même pour les programmes kernel, parce que TIGCC l'utilise.


Et d'ailleurs, ton argument est faux: TIGCCLIB utilise des ROM_CALLs par la table en $c8 même en mode kernel, donc il n'y a aucun moyen de savoir si le programme n'utilise pas une fonction de TIGCCLIB qui appelle un ROM_CALL non supporté.

Une idée encore meilleure pour les variables système: tu les pointe vers un endroit de la ROM mis à 0, comme ça les programmes pourront y écrire tant qu'ils veulent sans changer quoi que ce soit.

Et je te signale aussi qu'un programme pour kernel peut aussi utiliser USE_FLINE_ROM_CALLS. D'ailleurs, si tout le monde suit ton conseil (pas très intelligent d'ailleurs) d'abandonner la compatibilité avec tous les kernels sauf PreOs, tous les nouveaux programmes pour kernel (s'il y en a ) utiliseront des ROM_CALLs par ligne F parce que ça économise plein de place.

Donc ton excuse est complètement bidon: même avec un programme pour kernel, il n'y a aucun moyen de savoir de manière certaine quels ROM_CALLs il utilise!

...la baston général.....

GTools et PreRom risque de sortir en meme temps....ca ca me fera super bien rire, le match du siecle !!

en même temps , c'est-à-dire 2048 ?

Faut tout de même voir les avantages et les inconvenients du nosub!

D'accord, un nosub prend plus de place qu'un kernel car il faut tout reprogrammer. Par contre, pas besoin de kernel qui font plus planter les caltos qu'autre chose. Le mieux, ce serait d'offrir les 2 possibilités: kernel et nosub, comme TIGCC

Perso, je préfère le nosub, désolé pour ceux qui n'aiment pas

kernel qui font plus planter les caltos qu'autre chose

Mais bien sûr...
Et la marmotte...

mais fo arréter de dire ce genre de trucs...
tu as déjà essayé preOS ?
tu as déjà vu le nombre de bugs et de plantaghes qu'il était capable de ratraper ?

squale92 : bah au moins la propagande pour le nostub est efficace

ExtendeD> oué, il a été bien endoctriné

erf. non, sans rire, on dit que les progs kernels plantent, mais c'est juste car certain sont programmé en ASM pur et que les bugs sont plus dur à corriger. Mais un prog kernel en C/ASM bien programmé et le même prog nostub, ça sera la même chose au niveau des plantages !