.: live transmission :.

Il y a des soirs comme ça qui réservent plein de surprises !

Ce soir, sans trop y croire, j'ai jeté un oeil à vasm de Frank Wille, déjà auteur de PhxAss, un assembleur pour Amiga très performant, quasi 100% compatible avec Devpac, mais malheureusement absolument pas portable car écrit lui-même en assembleur.

Puis est venu vasm pour offrir un assembleur au compilateur vbcc du Dr. Volker Barthelmann. Cet assembleur est capable de générer du code pour différents processeurs, dont la série des 680x0 de Motorola. Avec son copain vlink, l'éditeur de lien, on peut générer des exécutables pour Amiga ou Atari ST (avec les symbôles siouplé !). La dernière fois que j'ai regardé, il manquait le support des macros, et contacté à ce sujet, Frank Wille m'a répondu que c'était l'affaire d'une soirée ou deux.

Un an est passé.. Et Frank Wille a donc passé une soirée sur vasm et a implémenté le support des macros !

Partons donc pour une petite description de la procédure de compilation sous Linux et un brin de mise en oeuvre.

Au travail, j'ai été amené à tartouiller sur l'ETL de Talend qui nécessite d'avoir quelques bases de programmation en Java. Et, pour faire suite à une conversation entre Hello et TME, je me suis dit que ça serait sympa de connaître un peu ce langage pour en découvrir ses forces et ses faiblesses.

Donc, je me suis lancé !

/* Tests en Java */

public class TestJava
{
        public static void main (String args[])
        {
                System.out.println("Hello, world");
        }
}

Donc, on n'oublie pas de nommer son fichier du même nom que la classe, en respectant la casse, on compile, et on admire le résultat.

Mes premières impressions sont que Java est un langage qui semble être plein de subtilités, bien trop verbeux à mon goût, il lui manque l'élégance d'un Ruby mais sa familiarité avec le C et le C++ sont moins déroutants que Ruby. Ce n'est donc pas pour autant que c'est un mauvais langage, et je n'ai notamment pas vraiment abordé son orientation purement objet, à l'instar de Ruby, faisant ainsi l'impasse sur l'atout le plus important de Java. Je vais essayer de continuer sur ma lancée, et peut-être marcher dans les traces de Keops.

Il s'agit donc de ne pas s'arrêter en si bon chemin !

Il était une fois un codeur dont le nom de scène est Oxbab, alors encore membre de Diamond Design. Ce groupe était actif sur Atari ST et a notamment collaboré avec Oxygene avant de ne faire qu'un avec ce dernier sur Amiga AGA, puis sur PC.

Diamond Design avait sorti en 1992 une démo appelé Brace. La démo était distribuée sous la forme d'une disquette normale sur laquelle se trouvait différents programmes TOS. Cette disquette était venue à point nommé lorsqu'il fallait coder un effet de rotozoom pour la Fantasia...

Après quelques semaines de tatonnement, j'ai réussi à programmer quelques petites choses inutiles sur mon Amiga. Voici le récit de mes aventures, sous la forme d'un petit mémento à l'attention de programmeur connaissant déjà la programmation du 68000.

Sur le forum "Coding" de dhs.nu, Peter se demandais à quoi pouvait bien servir les instructions CHK et CHK2. Ces instructions ont l'air plus ou moins inutiles aux yeux de beaucoup (dont je fais partie)... Et pourtant... Leonard/OXG nous explique une utilité possible de ces instructions, notamment pour réaliser une routine de clipping optimisée. Je cite:

I don't know that game code, but these intructions "may" be usefull for special ultra-optimisation :-) Explain:

In my fast mandelbrot routine, I use the instruction TRAPV. TRAPV flush an exeption if overflow flag is set. If not, it only takes 4 cyles. In a standard mandelbrot set, you have to check an exit condition at each iteration, and generally do 30 to 100 iterations before one and only exit. So using trapv takes only 4 cycles per iterations, instead of 8 for a BVS branch.

Anyway, I don't know the CHK timing instruction but it may be 4 cycles if CHK dn,dn exist. So in a loop where the exit condition does not occur very often ( say a 2d dot clipping routine), CHK may be usefull. ( again, IF it takes 4 cycles. If not, it's useless)

<lèche-bottes>
Ô maître Leonard, tu es grand !
</lèche-bottes>

Edit
Voici le détail de l'instruction CHK:
CHK - Check Against Bounds
This instruction checks its first operand against a data register's word contents. If the data register contains less than zero or greater than its first operand, a trap to the address specified by vector 6 occurs. Thus, CHK can be used to ensure that an element of an array is neither below nor above its boundaries. Syntax: CHK bounds, Dn where bounds is anything except an address register. Flags affected: All flags are undefined after this operation.

En français et en clair, cette instruction est effectivement toute adaptée au clipping. L'instruction teste si le registre de données (apparemment la seconde opérande) est inférieur à zéro ou bien supérieur au premier opérande, si oui le 68000 va déclencher une interruption type CHK (vecteur en $18). Donc, si le point ne doit pas être clippé, l'instruction consomme 12 cycles en tout, mais s'il doit être clippé, c'est 44 cycles + le temps d'exécution de la routine d'interruption + le RTE. Merci Leonard !