Question simple BITMAP - Page 2

./26: c'est la forme qui n'est pas très constructive...
Pour le moment, il n'y a qu'un fork du linker... mais ça pourrait très bien être le début d'un fork de TIGCC entier. Dois-je te rappeler qu'il n'y a pas que le linker qui a des choses en attente que tu ne peux ou ne veux pas merger ?

./30: je ne suis ni 100% d'accord ni 100% pas d'accord, mais si Kevin répond sur le même ton, ce topic va vraiment partir dans le décor

il y est déja, en partie grâce à Kevin mais aussi grâce à Thibaut qui met de l'huile sur le feu. Franchement Thibaut, tu le sais pas qu'il n'en a rien à faire des brevets? ton post est de la provoc gratuite et même pas justifiée.

Un autre truc qui me fait marrer, dans ce topic, ce sont les protagonistes.
Pensez à ceux qui ont fréquenté (éventuellement par intermittence) ce forum et ses discussions / engueulades passées (en particulier AMS native vs. kernel-based programming), depuis plus de six ans et demi (voir ma date d'inscription). Qui retrouve-t-on dans ce topic ?

Kevin, PpHd (qui sont rarement d'accord)
Thibaut, myself (qui sont rarement d'accord)
squalyl
Martial
Vertyos/Zephyr, qui intervient sur le plan technique et en tant que modérateur.

Même s'il manque des protagonistes (Flanker, etc.), ça fait un sous-ensemble emblématique, n'est-ce pas ?

Et il est peut-être utile de préciser que PpHd et Martial sont probablement les deux dernières personnes à coder sur TI68k :]

Il y en a plus que ça
Il y en a un autre rien que dans ce topic

Je code toujours sur TI-68k, cf. topics/111006-niveaux-de-gris-ams-304-patch/2#37 . La routine rajoutée était une requête d'Oliver Hoog, qui m'a envoyé les derniers sources de son projet pas plus tard qu'hier (il est embêté par la limite des 64 KB, il faut grignoter quelques KB sur le code du programme; première chose à faire, vu qu'il n'y en a qu'environ 320 octets, se débarrasser de ces foutus BSS).

Au fait, ibi0tux n'a pas eu de réponse à ./7

il est prévu que je me remette aussi aux 68k (mais y'a pas mal de code a faire sur pc avant), d'ou mon implication.

pour son ./7, ben avec plus d'infos on s'en sortirait mieux pour l'aider, aussi...

Et il y a moi qui m'occupe toujours de la chaîne d'outils, même si pas à la vitesse et de la manière que certains voudraient (il faut dire que je suis plus motivé pour travailler sur KDE sous Fedora, il y a beaucoup plus d'intéressés). AMHA, il faut de la détermination pour continuer aussi longtemps avec ces calculatrices, et cette même détermination implique aussi qu'on a tous nos idées et qu'on est prêts à les défendre dans les discussions.

Bah non.

bah si; c'est ça qui fait la richesse;

ce qui compte encore plus, c'est aussi écouter les idées des autres, et voir ce qu'on peut en tirer pour compléter les siennes.

(par exemple, le fait que tigcc soit en beta pourrait ouvrir la porte a des modifications non encore stabilisées, etc. ce qui permettrait a tous de tester les dernières évolutions, en leur permettant de murir avant la release officielle...)

Kevin Kofler (./25) :
Ça ne va que nuire à ceux qui veulent compiler/assembler PedroM, comme ta version modifiée de A68k à l'époque (qui a créé des tonnes de questions "Pourquoi ai-je une erreur quand je veux compiler PedroM?").

Ce que j'ai prévu (et il me semble à la lecture des autres réponses, que les autres n'ont pas aussi compris) est que PedroM fournisse sa version de ld-tigcc qui sera compilé dans le répertoire bin.
Je n'ai pas encore prévu de remplacer tout tigcc, mais ca me tente (genre les headers 'stdint.h' manquant depuis X années).

Kevin Kofler (./26) :
Il annonce un fork de ld-tigcc, pas de TIGCC en entier. Et je n'ai fait que répéter ce que je pensais avoir clairement dit dans l'autre topic.

Tu avais annoncé qu'il manquait :

1 rajouter la nouvelle option partout: KTIGCC 1 et 2, TIGCC IDE, TIGCC.EXE, tprbuilder (ton patch pour le tigcc POSIX m'a l'air bon, mais c'était probablement le plus facile à adapter parmi tous ceux-là),
2 documenter la nouvelle option,
3 trouver une solution pour le problème de l'optimisation des opérandes de destination.

1. Si tu n'es pas capable de faire çà, je ne vois pas en quoi tu peux être qualifié de mainteneur.
2. Je t'ai proposé la documentation.
3. Tu as juste demandé de trouver une solution, et je n'en ai pas à te proposer (pour les curieux, à l'heure actuelle, l'infrastructure de ld-tigcc ne permet d'optimiser que les relocations sources car dans ces cas là, on peut conjecturer que l'opcode sera soit 2 ou 6 octets plus loin avec une grande probabilité, et donc modifier l'opcode - pour les relocations destinations, la probabilité de générer un mauvais code dans une rom de la taille de PedroM est à mon avis suffisament élevé pour ne pas le faire de cette façon - A l'heure actuelle, le patch proposé fonctionne parfaitement, est 100% fonctionnel et serait utile à d'autres que moi - Punix par exemple). Donc sauf si tu vois une solution, je ne vois plus que le point 1 de bloquant.

squalyl : Oui, voilà, on est d'accord. On a pas interprété le message de Kevin de la même façon.

c'est vivant punix?

et pour un OS qui n'a aucune ambition de compatibilité AMS, on s'en fout un peu de tigcc non?
moi j'ai commencé un OS aussi, il est compilé par gcc4.1 68k officiel, et lié par un ldscript perso. tout marche nickel.

Ce que j'ai prévu (et il me semble à la lecture des autres réponses, que les autres n'ont pas aussi compris) est que PedroM fournisse sa version de ld-tigcc qui sera compilé dans le répertoire bin.

Personnellement, je me doutais que tu ferais quelque chose comme ça.
Je l'ai déjà fait pour TICT-Explorer, en attendant qu'un de mes patches à tprbuilder, rendant moins inutilisables les TPR pour TICT-Explorer (2 TPR au lieu de 2 TPR * 6 langues, c'est mieux pour la maintenance ), soit intégré et qu'une beta comprenant ce patch soit releasée.

Lionel Debroux (./33) :
Vertyos/Zephyr, qui intervient sur le plan technique et en tant que modérateur.

Absolument pas, comme l'indique l'absence de balises [modo]...

Euh... je me suis mal exprimé.
Dans _ce_ topic, tu n'interviens en effet pas en tant que modo. Cependant, ce que je voulais dire, c'est que tu es intervenu pour modérer certaines engueulades, il y a longtemps

PpHd (./40) :
1. Si tu n'es pas capable de faire çà, je ne vois pas en quoi tu peux être qualifié de mainteneur.

Je n'ai pas eu le temps, donc forcément ça attend.

2. Je t'ai proposé la documentation.

Pas en le format nécessaire (le format .hss de Sebastian Reichelt). Je peux la reformater, mais là encore ça va prendre du temps.

3. Tu as juste demandé de trouver une solution, et je n'en ai pas à te proposer (pour les curieux, à l'heure actuelle, l'infrastructure de ld-tigcc ne permet d'optimiser que les relocations sources car dans ces cas là, on peut conjecturer que l'opcode sera soit 2 ou 6 octets plus loin avec une grande probabilité, et donc modifier l'opcode - pour les relocations destinations, la probabilité de générer un mauvais code dans une rom de la taille de PedroM est à mon avis suffisament élevé pour ne pas le faire de cette façon

J'ai proposé une solution possible, qui nécessite de modifier aussi les 2 assembleurs (mais c'est le cas de toutes les solutions à ce problème AMHA), si tu n'as pas l'envie ou le temps (ou les connaissances ) d'implémenter ça, je peux le faire, mais là encore ça va prendre du temps.

De plus, je veux sortir une 0.96 stable enfin (et la bêta 9 avant, qui attend depuis des mois), pas introduire des nouveautés déstabilisantes et incomplètes.

squalyl (./39) :
(par exemple, le fait que tigcc soit en beta pourrait ouvrir la porte a des modifications non encore stabilisées, etc. ce qui permettrait a tous de tester les dernières évolutions, en leur permettant de murir avant la release officielle...)

Justement, le plan est de finir enfin le cycle interminable de bêtas de TIGCC 0.96!

Est-ce qu'une bonne solution ne serait d'installer pas d'installer ces libs en archive à l'installation de PreOS/PedroM, de rendre le secteur kivabien de flash exécutable, après avoir modifié les-dites libs pour ne plus avoir de smc ? (juste garder les vars quelque part dans le handle du kernel par exemple?)

C'est bourrin, ça
Sur PedroM, je pense que PpHd n'a pas activé la protection d'exécution en archive, non ?
Pour changer la protection d'exécution en archive, il faut désactiver la Protection, donc embarquer le code de déprotection/reprotection dans PreOS.

Le SMC est sympa pour l'optimisation taille, donc l'enlever risque de bouffer des centaines d'octets

Tu veux qu'on te dise quoi? Que ton idée est nulle à ch**r?

"ton idée est nulle a ch**r" ()

Ton idée est interessante en théorie. En pratique,
on a quand même 180K de RAM sous AMS. C'est pas comme si on était vraiment juste en mémoire.
Si tu veux les garder en fichier, le moindre GC peut faire remapper ta librarie ailleurs, et pouf le crash (et pour comprendre d'où ca vient...)
Si une librairie est appelée en archive, il faut qu'elle récupère son pointeur vers ses données en RAM, et c'est pas simple à faire si l'os ne le gère (en plus que la tool chain tigcc ne le supporte pas).

et locker un handle, non?

Ah ouais, c'est vrai que le GC peut casser l'exécution en archive

squalyl (./55) :
et locker un handle, non?

Ca ne marche pas pour les fichiers archivés.

ben tu patches la routine de GC (ça doit même être jouable sans toucher à la ROM, tu devrais pouvoir intercepter la touche ENTER si la boîte de dialogue actuelle est une boîte de GC)

récupérer le pointeur vers les données : nouveau vecteur et/ou line 1111 emulator, ou bien simplement paramètre supplémentaire ^^ (qui aurait l'avantage de permettre la réentrance)

Puisque tu es motivé, je te laisse le coder

Je crois que t'as raté l'utilisation de la 2è personne dans mon post