240

Folco (./238) :
c'est bien ça la différence entre le bon codeur et le mauvais codeur hein tongue

Le bon codeur c'est celui qui s'est rendu compte à quel point les conventions qu'il utilise étaient illogiques et bourrées de pièges, mais qui continue à les imposer pour "rentabiliser" sa connaissance des pièges ? trifus

« The biggest civil liberty of all is not to be killed by a terrorist. » (Geoff Hoon, ministre des transports anglais)

241

GoldenCrystal (./239) :
./237> Peut-être que c'est le critère humain, mais le critère au niveau du CPU est comme je le décris, et c'est beaucoup mieux pensé (et addq/subq n'est pas un cas spécial, le cpu ignore tout simplement le champ S lorsque la destination est un registre d'adresse, ce qui est facile vu qu'il n'y a aucune extension de taille à faire, en revanche c'est effectivement ambigu que l'instruction modifie ou pas les flags selon la destination... ^^)Car là ou avec un CMP générique tu devrais faire des tests au niveau du CPU pour vérifier la validité de l'instruction, ici tu n'as même pas à le faire, c'est directement impossible de coder un cmp.b <ea>, An.

Sauf que ce n'est pas toujours vrai, pour movea ce n'est pas une distinction qui a un sens pour le CPU : tu pourrais coder un movea.b, et movea est simplement un move quelconque avec un An en destination. Si c'était ça la vraie raison il faudrait supprimer movea...
Après c'est sur qu'au niveau assembleur résultant il aurait été mieux de cacher les détails d'implémentation, mais il faut bien que tu puisses assembler tes instructions correctement donc il faut faire la distinction quelque part ^^

Tu vas me faire croire que quelqu'un qui est capable d'écrire un assembleur ne serait pas capable d'assembler cmp si la destination est un registre d'adresse ? laught
Moi ça ne me choque pas qu'un assembleur convertisse automatiquement les <ALU> <ea>,<ea> en <ALU>[A|I] <ea>,<ea>, c'est même ce que j'aurai fais si j'avais codé mon assembleur, mais que deux opcodes (même si identiques au niveau humain, et encore ^^) différents soient nommés différemment me semble aussi assez logique. tongue

Ben l'admettre en tant que rétrocompatibilité, pourquoi pas : mais l'imposer en tant que seule et unique façon propre, c'est ridicule.

« The biggest civil liberty of all is not to be killed by a terrorist. » (Geoff Hoon, ministre des transports anglais)

242

PpHd (./226) :
Bon va falloir que je mette a68k en plus pour preos avec auto-compilation + modification de PedroM pour utilisation de celui de preos.

Tu es censé convertir ta source à GNU as plutôt.

J'ai aussi au moins une raison pour toi: GNU as te permet d'utiliser des différences d'adresses où les labels sont dans des fichiers compilés séparément.
Folco (./229) :
pencil Aujourd'hui, on ne compile plus PedroM avec TIGCC. Kevin, c'est normal ? confus

J'ai toujours eu besoin de patcher PedroM pour le compiler avec TIGCC (cf. pedrom-ld-tigcc), je commence à avoir l'habitude aussi. sad

D'ailleurs, je trouve ça fortement ironique qu'il faille un assembleur non-libre pour assembler un OS sous GPL. Folco, n'est-ce pas toi l'extrémiste du libre, au point de préférer BLAG à Fedora? Venant de ta part, c'est particulièrement hypocrite de défendre l'usage de A68k.
Alors pourquoi ne peut-on pas faire de différence de labels entre deux sources (ce qui au passage, oblige à fusionner les sources, même si on aime pas les include "truc.asm") ?

Ce n'est pas un bogue, c'est une fonctionnalité que GNU as a et que A68k n'a pas, tout simplement, il n'a pas été conçu pour permettre ça.
Il y a un problème avec les equate, de mémoire, je ne peux pas utiliser mylib::myfunc, je dois utiliser mylib@00xy à la place. Et tu le sais, on en a parlé dans cette rubrique, mais tu n'as pas voulu mettre sur ta todo.

Probablement parce que ce n'était pas un bogue non plus, mais il faudra que tu me montres exactement la discussion pour que je puisse te répondre.
Autre bug : MULU.L est compilé, peut-être bien aussi les MULS/DIVU/DIVS, ce qui est anormal.

Si je corrige tous ces bogues "accepts-invalid", la moitié des sources existantes pour A68k ne compilent plus (on trouve plein de MOVEQ.W etc. dans les sources parce que A68k a toujours accepté), ce qui serait quand-même gênant pour un assembleur qu'on n'inclut que pour la compatibilité antérieure. Donc il est impossible de corriger ces bogues dans A68k, si tu veux un assembleur qui n'accepte que du valide, utilise GNU as.
avatar
Mes news pour calculatrices TI: Ti-Gen
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité

243

Moi j'ai été convaincu par l'argumentation de Pollux dans le débat cmpa/cmpsmile
Kevin Kofler (./242) :
GNU as te permet d'utiliser des différences d'adresses où les labels sont dans des fichiers compilés séparément.
Et il permet d'écrire par exemple (label1-label2)/4 ? Et même dans le cas d'un simple label1-label2, quel est le format de fichier objet qui gère ça (quand un les labels sont dans différents fichiers sources hein) ?
avatar
« Quand le dernier arbre sera abattu, la dernière rivière empoisonnée, le dernier poisson capturé, alors vous découvrirez que l'argent ne se mange pas. »

244

Sasume (./243) :
Et il permet d'écrire par exemple (label1-label2)/4 ?

Seulement si tu n'es pas en mode all-relocs (comme avec A68k), et tu ne peux pas utiliser ça avec des labels dans les fichiers compilés séparément (pour la même raison; la question ne se pose pas avec A68k parce qu'il ne gère même pas label1-label2 avec des labels dans des fichiers compilés séparément). Et cette raison, c'est qu'il y a des relogements positifs et négatifs, mais il n'y a pas de quarts de relogements. Or, en mode all-relocs, ou pour représenter les différences entre labels externes, il faut une paire de relogements (positif+négatif), donc on ne peut pas diviser par 4. (Le mode all-relocs est le mode d'assemblage utilisé pour permettre les optimisations au niveau du linker.)

(Pourquoi faut-il que je répète cette explication sans arrêt? sad J'ai déjà expliqué ça plusieurs fois dans des forums publics!)
Et même dans le cas d'un simple label1-label2, quel est le format de fichier objet qui gère ça (quand un les labels sont dans différents fichiers sources hein) ?

Extension TIGCC au format COFF. Enfin, plus précisément, le relogement négatif 32 bits est présent dans le standard COFF, mais normalement pas utilisé, les relogements négatifs 16 bits et 8 bits sont des extensions TIGCC.
avatar
Mes news pour calculatrices TI: Ti-Gen
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité

245

246

Que à la limite, le .l est acceptable pour tous, et le .w pour lea et jsr si jamais le mode d'adressage est Abs.W (uniquement), et le .b pour aucun (évidemment tongue)
Après faut voir aussi si tu acceptes jsr.l (xxxx).w (très très moche grin) et autres joyeusetés...
avatar
Le scénario de notre univers a été rédigée par un bataillon de singes savants. Tout s'explique enfin.
T'as un problème ? Tu veux un bonbon ?
[CrystalMPQ] C# MPQ Library/Tools - [CrystalBoy] C# GB Emulator - [Monoxide] C# OSX library - M68k Opcodes

247

248

Folco (./245) :
Toujours dans la lignée de mes "découvertes". Lea, pea, jmp,jsr et d'autres sont donnés comme "unsized". A votre avis, c'est mauvais d'accepter un jsr.l 0x01234568 ? Le L a exprime bien l'adressage en (xxx).l, non ? Il vous en semble quoi ?

Oui si tu veux être très strict je te conseille de refuser une taille pour lea/jmp/jsr, par contre pour pea le .l est clairement correct : contrairement à lea/jmp/jsr qui modifient des registres d'adresse ou pc et donc qui ont une taille implicite, pea met un longword sur la pile. Mais point de vue rétrocompatibilité il y a des chances que lea.l soit assez courant, et puis c'est pas non plus franchement choquant.

La suggestion de golden m'a l'air un peu bof, normalement on considère les effective address comme des boîtes noires et il n'y a pas vraiment de raison de distinguer entre abs.w et abs.l en dehors de l'effective address elle-même...

« The biggest civil liberty of all is not to be killed by a terrorist. » (Geoff Hoon, ministre des transports anglais)

249

Kevin Kofler (./244) :
(Pourquoi faut-il que je répète cette explication sans arrêt? frown.gif J'ai déjà expliqué ça plusieurs fois dans des forums publics!)

fais une faq gni

250

>Pourtant un cmpa sera mis à la place. Pourquoi trouves-tu que c'est pire ? EXG an,dn est interdit également, je veux dire ni plus ni moins, même si c'est 100 fois moins évident pour le codeur, en effet.
J'avais mal compris ce que tu comptais faire. Désolé pour ma remarque.
Kevin Kofler (./242) :
Tu es censé convertir ta source à GNU as plutôt.

Pas envie.
Kevin Kofler (./242) :
J'ai aussi au moins une raison pour toi: GNU as te permet d'utiliser des différences d'adresses où les labels sont dans des fichiers compilés séparément.

Tant qe ca ne supporte pas le quart de relogement, ca ne m'interesse pas.
Kevin Kofler (./242) :
J'ai toujours eu besoin de patcher PedroM pour le compiler avec TIGCC (cf. pedrom-ld-tigcc), je commence à avoir l'habitude aussi. frown.gif

Et la 0.82 ?
Kevin Kofler (./242) :
D'ailleurs, je trouve ça fortement ironique qu'il faille un assembleur non-libre pour assembler un OS sous GPL.

Pas ma faute si GNU as supporte pas la syntaxe 68000 standard.

251

C'est à toi de t'adapter aux outils libres, pas l'inverse.
avatar
Mes news pour calculatrices TI: Ti-Gen
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité

252

C'est à toi de t'adapter aux outils libres, pas l'inverse.

Quoted grin
Par son énormité, ce commentaire me fait penser à celui que tu m'as envoyé en privé, dans lequel tu défendais l'utilisation de mesures de filtrage (avec mention explicite de la solution technique du blocage d'IP, pourtant connue comme particulièrement inefficace et injuste) pour empêcher l'accès à un logiciel libre grin


Puisque c'est un outil libre, il se pourrait aussi que ce soit lui qui adapte les outils libres à ses besoins. C'est une des 4 libertés, rappelle-toi wink
Liberté qui est déjà utilisée par des membres de la communauté pour divers morceaux de TIGCC, d'ailleurs...
avatar
Membre de la TI-Chess Team.
Co-mainteneur de GCC4TI (documentation en ligne de GCC4TI), TIEmu et TILP.
Co-admin de TI-Planet.

253

nan mais lol... triso un outil par définition doit s'adapter au travail, pas l'inverse gol
On aura tout lu laught

254

Lionel Debroux (./252) :
Puisque c'est un outil libre, il se pourrait aussi que ce soit lui qui adapte les outils libres à ses besoins. C'est une des 4 libertés, rappelle-toi wink

S'il rajoute un mode de compatibilité A68k à GNU as ou nous fait une autre alternative libre à A68k, tant mieux, justement! Le problème, c'est qu'il utilise un assembleur non-libre.
Pen^2 (./253) :
un outil par définition doit s'adapter au travail, pas l'inverse

Dans ton monde des rêves peut-être... Dans la réalité, les outils sont ce qu'ils sont, il faut s'y adapter. Sinon, moi, je veux une voiture qui ne consomme rien, qui peut être utilisée sans permis et qui me téléporte n'importe où au monde en une milliseconde. Vas-y, adapte-moi l'outil au travail. tongue
avatar
Mes news pour calculatrices TI: Ti-Gen
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité

255

Kevin Kofler (./255) :
Le problème, c'est qu'il utilise un assembleur non-libre.


une fois bootstrapé on s'en tape non?

256

Je parle de PpHd et de PedroM. L'assembleur on-calc de Martial ne pourra pas assembler PedroM.
avatar
Mes news pour calculatrices TI: Ti-Gen
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité

257

258

Il fera peut-être une version PC ?
avatar
« Quand le dernier arbre sera abattu, la dernière rivière empoisonnée, le dernier poisson capturé, alors vous découvrirez que l'argent ne se mange pas. »

259

260

Euh merde j'avais déjà oublié... triso
avatar
« Quand le dernier arbre sera abattu, la dernière rivière empoisonnée, le dernier poisson capturé, alors vous découvrirez que l'argent ne se mange pas. »

261

Avec un bon préprocesseur bien adapté, de l'asm ça peut se convertir en C tongue
(J'ai jamais dit que c'était propre par contre, et puis faut quand même réécrire les parties dépendantes de l'OS wink )
avatar
Le scénario de notre univers a été rédigée par un bataillon de singes savants. Tout s'explique enfin.
T'as un problème ? Tu veux un bonbon ?
[CrystalMPQ] C# MPQ Library/Tools - [CrystalBoy] C# GB Emulator - [Monoxide] C# OSX library - M68k Opcodes

262

on peut coder en asm pour PC aussi tu sais...
Tout ce qui passe pas par le port 80, c'est de la triche.

263

Encore faut-il dénicher un convertisseur 68k->x86 tongue
avatar
Un site complet sur lequel vous trouverez des programmes et des jeux pour votre calculatrice TI 89 / Titanium / 92+ / Voyage 200 : www.ti-fr.com.
Quelques idées personnelles ici.

264

onur (./262) :
on peut coder en asm pour PC aussi tu sais...

Du temps où il n'y avait pas 5000 variantes d'architecture x86 et que la liste des instructions pouvait encore tenir dans un livre de 100 pages (haha) oui, mais maintenant c'est plus trop le cas.
A part ça je vois pas le rapport vu que martial code en asm 68k...
avatar
Le scénario de notre univers a été rédigée par un bataillon de singes savants. Tout s'explique enfin.
T'as un problème ? Tu veux un bonbon ?
[CrystalMPQ] C# MPQ Library/Tools - [CrystalBoy] C# GB Emulator - [Monoxide] C# OSX library - M68k Opcodes

265

Ben, tu prends une architecture minimum et tu codes pour celle-là, et tu t'en fous des instructions bizarres si tu ne cherches pas à avoir l'optimum en vitesse (ce qui de toute façon n'est pas possible étant donné les nombreux CPUs x86). Et il faut très peu de modifications pour porter de l'ASM x86 en x86_64. (D'ailleurs, il est déjà presque envisageable de faire du x86_64-only de nos jours, presque toutes les nouvelles machines sont 64-bits.)
avatar
Mes news pour calculatrices TI: Ti-Gen
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité

266

Kevin Kofler (./265) :
(D'ailleurs, il est déjà presque envisageable de faire du x86_64-only de nos jours, presque toutes les nouvelles machines sont 64-bits.)

Je sens que tu vas t'en donner à coeur joie pour troller, mais tous les OS ne sont pas 64 bits, et même ceux qui le sont n'ont pas toutes leurs libs compatible 64 bits...

« The biggest civil liberty of all is not to be killed by a terrorist. » (Geoff Hoon, ministre des transports anglais)

267

268

Folco, wine.i386 marche très bien sous Fedora x86_64.
avatar
Mes news pour calculatrices TI: Ti-Gen
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité

269

Pollux (./266) :
et même ceux qui le sont n'ont pas toutes leurs libs compatible 64 bits...

Dans Fedora, presque tous les paquetages sont compatibles x86_64, les exceptions documentées (normalement toutes sont censées l'être) sont WINE (parce que la version 64 bits est préliminaire et ne gèrera de toute façon jamais les binaires 32 bits, qui sont les plus courants), athcool (ne sert que pour de vieux Athlons 32 bits), Gambas 1 (mais Gambas 2 est disponible), MoscowML et Ikarus (les 3 derniers sont des compilateurs ou interpréteurs rarement utilisés, rien d'autre dans Fedora ne les utilise à ma connaissance). Bref, dire que Fedora "n'a pas toutes ses libs compatible 64 bits", c'est quand-même couper les cheveux en 4.
avatar
Mes news pour calculatrices TI: Ti-Gen
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité

270

Kevin Kofler (./269) :
sont WINE (parce que la version 64 bits est préliminaire et ne gèrera de toute façon jamais les binaires 32 bits, qui sont les plus courants)


et si un exe64 a besoin de lancer un exe32 ?
Tout ce qui passe pas par le port 80, c'est de la triche.