Kevin Kofler
:

Pollux
: Avoue que ce n'est pas la première fois qu'on te dit que c loin d'être la seule différence entre GAS et A68k...

Mais c'est celle dont tout le monde se plaint, le reste, ce sont des avantages!

C'est un avantage de ne pas pouvoir utiliser des labels locaux dignes de ce nom ?

Et les ":" après les labels ?

C'est fait exprès parce que c'est obligatoire pour avoir une syntaxe insensible à l'indentation.

Oui, et c'est tout l'intérêt d'avoir une syntaxe sensible à l'indentation Et justement, avec le patch que je t'ai proposé, tu peux avoir ta syntaxe insensible à l'indentation (en revanche, ce n'est pas insensible aux newline, mais c'est le cas aussi pour le préprocesseur C et tu ne t'en plains pas )

Quel patch? Le même que pour le maximum de lignes?

Non, celui de la suppression du whitespace avant les labels... (patch que je t'ai proposé de faire, pas d'appliquer, hein )

Et si tu codes proprement, même avec A68k, tu mets toujours les : après les labels! Si tu veux voir tes labels dans l'IDE, tu n'as pas le choix de toute façon.

Non, n'importe quoi, je vois pas pkoi c plus propre. Si votre IDE est mal faite, tant pis, mais moi personnellement je ne mets des ":" qu'après des labels globaux.

Si tes labels sont locaux, ne pas les avoir dans la liste des fonctions/labels de l'IDE est limite un avantage.

Ben oui, mais je vois pas ce qui en empêche la coloration syntaxique...

Et les labels locaux ?

0: bra.s 0b marche très bien ici.

Ca t'arrive d'imaginer qu'il peut y avoir des progs en assembleur de plus de 3 instructions ? D'ailleurs on voit bien ce qui se passe : pour les trucs en GAS un minimum long (routines de gris), tous les labels sont préfixés par un horrible truc avec des underscores de partout, alors qu'en A68k il suffit de mettre un '\'...

J'ai bien utilisé des 47: dans cbscanf, moi.

Et t'en es fier ?
Alors les *features* des labels locaux à la GAS, c'est :
- les numéros de label sont 100x plus parlants que des noms, c'est bien connu (d'ailleurs c'est pour ça que le Basic est mieux que le C)
- qd tu bouges du code, ça te fait hyper plaisir d'avoir à modifier les directions des sauts de tous tes labels (puisqu'avec les labels à la GAS, il faut spécifier les directions de chaque saut )

Et les commentaires avec moins de 4 caractères de délimiteurs (/**/) ?

Tu connais |?

OK. (et au passage ça empêche de se servir du OU logique dans les constantes...)

--bitwise-or. Mais faut choisir.

Hélas... Dans a68k il ne faut pas choisir.

Tu peux patcher A68k pour qu'il fasse un s/^\s*(\w+/\1/ (s'il ne le fait pas déjà), tu ne vas pas me faire croire que tu n'en es pas capable.

Ce n'est pas ça qui résoudra le problème fondamental.

Qui est ?

Que la syntaxe est faite de partout pour être sensible à l'indentation. Par exemple: "The only values a label cannot take are the register names - A68k can distinguish between the same name used as a label, instruction name or directive, macro name, or section name."

Ben non, si tu veux être insensible à l'indentation, tu peux très bien rajouter le ":" (qui n'est pas gênant dans GAS, mais qui dans A68k devient la mer à boire )
Perso je préfère être sensible à l'indentation et ne pas mettre de ":", en tout cas. Et tout le monde serait heureux avec la syntaxe A68k