subtilités asm - Page 2

Si. Ils ont appris la lecon : la backup de la calc ne marche plus
Sinon, c'est vrai qu'ils changeraient aussi pas mal de chose... s'ils sont pas trop flemmards.

arf mais s'ils n'oublient aucune faille ds une future version, ça va etre cho le kernel
tu serais heureux kevin ?

Il y aura tjrs des failles...

Miles>ok... dc dans ce cas, c a68k qui a "inventé" ces instructions... je trouve ça un peu con... enfin bon.
Kevin>si tu veux supprimer la correction automatique des erreurs ds a68k, pourquoi ne supprimes-tu pas déjà la prise en charge des instructions qui n'existent pas sur le 68000 ?
et puis quelle était la raison de cet ajout??

dec et inc ne sont pas des instructions A68k, mais des macros définis dans OS.h et doorsos.h. Et je ne vois aucun intérêt à les virer.

Et "correction automatique des erreurs" est un euphémisme. "Non-reconnaissance des erreurs comme telles" serait plus approprié. Je réfléchis encore si je vais changer cela dans les versions futures. Et ça ne sera certainement pas pour tout de suite. (J'ai autre chose à faire jusqu'à noël.) De toute façon, il faudra probablement attendre au moins TIGCC 0.93 pour l'avoir. Sauf si vraiment aucune release de TIGCC n'est prévue dans les 3 mois qui suivent et que je décide donc qu'une release séparée est la meilleure idée.

et puis aussi, pourquoi ne pas carrément virer le remplacement automatique des add.x xx,ax par adda, pareil pour movea, addi #machin,xx, etc, etc...
paske je suis sur qu'il y en a qui ne savent pas que ça existe...
et pis c bien de savoir EXACTEMENT ce qu'il y a dans le code... pas se demander ce qu'a modifié le compilo sans demander...

En fait add et adda, par exemple, je suppose que pour les autres c'est la même chose, les codes sont les mêmes, ce sont les opcodes qui sont différents. Ce sont donc les mêmes instructions pour le proc.

Non, pour virer le add -> adda, c'est définitivement non. add ...,an n'existe pas (du moins pas que je sache), donc la seule manière de le coder qui a un sens est adda ...,an.

Ce n'est pas la même chose que pour moveq.w, qui est du non-sens: moveq détruit toujours le long entier. Si on écrit moveq.w en pensant que ça existe, ça peut entraîner des bogues stupides.
[edit]Edité par Kevin Kofler le 23-11-2001 à 23:49:44[/edit]

>add ...,an n'existe pas
donc pourquoi le corriger?

certaines personnes croient que ça existe...
juste parceque le compilateur ne leur a rien dit quand elles ont mis ça dans un prog pour la première fois...

>donc la seule manière de le coder qui a un sens est adda ...,an
ben oui! alors pourquoi des gens continueraient-ils d'écrire quelquechose qui n'a pas de sens sans le savoir ???

c'est con...

Non, je ne peux pas changer cela par peur de me faire lyncher. Et je devrais changer mes propres programmes également. Mais ce que je peux faire, c'est rejeter ces instructions si -n (pas d'optimisations) est spécifié. -n est là pour les puristes.

ha oui! ça c bien, de pouvoir paramétrer ça...
ok ok... ça y est déjà -n ??
j'ai pas bien du lire la doc...

moi je l'ai jamais lue
n'empèche que je suis oblligé de compiler avec le vieux a68k, car les nouveuax marchent pas dans tous les cas, et ça je trouve ça vraiment étrange !

Kevin, je crois que je vais te mailer toute la source de thunder !

>sBibi: ok ok... ça y est déjà -n ??

Oui, mais pour l'instant ça ne fait que désactiver les optimisations (style MOVE.L->MOVEQ, ...), pas les trucs du genre ADD->ADDA.

>HerveRV: Kevin, je crois que je vais te mailer toute la source de thunder !

Oui, je pense que c'est le mieux. J'espère que ce n'est pas excessivement grand (style plus de 200-300 KO).
[edit]Edité par Kevin Kofler le 27-11-2001 à 06:54:04[/edit]

non, je pense que ça dois passer.

si tu vois des conneries, t'hésiteras pas à me les signaler, et même si ça te chante de les corriger !
si t'as aussi envie de convertir le prog en nostub, je pense que ça devrait pas trop te prendre de temps, tu peux, bien sur, mais faudra que je te refile rv_lib.asm si je ne te l'ai pas déjà redonné

Ca y'est ! Encore un !
Je me sens de plus en plus seul

mais non mais non

tu viens avec moi dans la danse ?

je suis ac toi PpHd !

T'es trop gentil !

#battement_de_paupiere_ac_de_longs_cils#

#coeur_qui_bat_super_mega_vite#
Brouh, arrete.. Je vais finir par craquer et me plonger dans tes yeux couleur creme.

#syncope#
@+

hu²

tu peux écrire huhu en entier, feignant

non, PpHd, je lui proposais, afin que tous les anti-kernels puissent en profiter.
t'inquiete pas, la preuve, si je voulais faire du nostub, j'aurais pas commencé mon raycasting en mode kernel
je resterai toujours de ton coté, t'inqiète pas (), je suis pour, mais pas contre le nostub. le seul truc qui me fait ièch, c que plein de monde ne peut pas jouer à mes progs

quel est le #$$%@ qui a commencé à faire des progs nostub en 1er !

'Plein de mondes' ? Personne oui ! S'ils voulaient y jouer, ils y joueraient !

>HerveRV: quel est le #$$%@ qui a commencé à faire des progs nostub en 1er !

Rusty Wagner. Le nom du programme en question: PlusShell. Et oui, les kernels eux-même sont bien en _nostub.

Sinon, il y a eu basiclib et secure d'Alban Gervaise (mais c'était écrit de manière encore plus sale que les programmes pour kernel).

Les premiers programmes en _nostub écrits de manière portable grâce à la documentation de TIGCCLIB (et grâce à TIGCCLIB lui-même) étaient CBlaster et CReversi de Zeljko Juric. C'étaient les 2 seuls jeux "en assembleur" (en C, en fait) à fonctionner sur HW2 AMS 2 dès le début.

Et le jeu qui a vraiment popularisé le _nostub était TI-Chess de Thomas Nussbaumer.
[edit]Edité par Kevin Kofler le 30-11-2001 à 21:03:27[/edit]

bah c pas malin, maintenat on est emmerdés avec ça !
du coup, le sujet du concours excluait tous les programmeurs qui se sont pas adaptés, ou qui comme moi préfèrent le mode kernel....

Ne t'inquietes pas. Je corriges ca en remettant dans le linkeur l'option : nokernel.
(Cette option permet de rajouter un mini-kernel au debut pour pouvoir faire le linkage).
(En plus de l'option mistub).

et ça va pas etre le mini-bordel, j'éspère
car sinon, ça va pas etre utilisé

Mais non. C'est moi qui morfle pour le faire. Pas les utilisateurs. Et en plus, en nokernel, si un kernel est installe, ca utilise ce kernel au lieu de celui installe.