1

Salut !
Voila j'ai fait moi même cette routine pour afficher des sprites car il n'en existe pas des comme celles là dans extgraph.
c'est pour afficher un sprite en niveaux de gris, avec mask, clippée par des valeurs constantes définies et dont la taille horizontale est un multiple de 8 quelconque.
Vu que je connais pas assez l'asm pour la faire en asm, je l'ai faite en C.

void grayclipspriteX8_mask(short Xscreen, short Yscreen, short width, short height,
unsigned char * img0, unsigned char * img1, unsigned char * mask,
unsigned char *Plane0, unsigned char *Plane1)
{
	register short i, j;
	short width2, width3;
	short offset = (Yscreen * 30);
	short clippedup, clippeddown;
	unsigned short shift = Xscreen % 8, hmshift;
	
	BYTE byteMask;
	BYTE byteImg0;
	BYTE byteImg1;

	
	if (Xscreen < 0)
	{
		shift = (8 + shift) % 8;
		offset += (Xscreen-7) / 8;
		clippeddown = (CLIP_DOWN - 1) * 30;
		clippedup = (CLIP_UP - 1) * 30;
	}
	else
	{
		offset += (Xscreen / 8);
		clippeddown = CLIP_DOWN*30;
		clippedup = CLIP_UP*30;
	}
	 
	if (shift)
		width2 = width + 1;
	else
		width2 = width;

	hmshift = 8 - shift;
	width3 = width2 - 1;

	for (i=0; (i<height) && (offset < clippeddown); i++)
	{
		if (offset >= clippedup)
		{
			j=0;
			if ((offset + j - ((Yscreen+i) * 30)) < CLIP_RIGHT)
			{
				if ((offset + j - ((Yscreen+i) * 30)) >= CLIP_LEFT)
				{				
					if (shift)
					{
						byteMask = (*mask >> shift) | (0xFF << (hmshift));
						byteImg0 = (*img0 >> shift);
						byteImg1 = (*img1 >> shift);
					}
					else
					{
						byteMask = *mask;
						byteImg0 = *img0;
						byteImg1 = *img1;
						mask++;
						img0++;
						img1++;
					}

					Plane0[offset + j] &= byteMask;
					Plane0[offset + j] |= byteImg0;
					Plane1[offset + j] &= byteMask;
					Plane1[offset + j] |= byteImg1;
				}
				else
				{					
					if (!shift)
					{
						mask++;											
						img0++;
						img1++;
					}
				}
			}
			else
			{
				mask++;											
				img0++;
				img1++;
			}
			for (j=1; j<width3; j++)
			{
				if ((offset + j - ((Yscreen+i) * 30)) < CLIP_RIGHT)
				{
					if ((offset + j - ((Yscreen+i) * 30)) >= CLIP_LEFT)
					{
						if (shift)
						{
							byteMask = (*mask << (hmshift)) | (*(mask+1) >> shift);
							byteImg0 = (*img0 << (hmshift)) | (*(img0+1) >> shift);
							byteImg1 = (*img1 << (hmshift)) | (*(img1+1) >> shift);
						}
						else
						{
							byteMask = *mask;
							byteImg0 = *img0;
							byteImg1 = *img1;
						}
						mask++;
						img0++;
						img1++;
						Plane0[offset + j] &= byteMask;
						Plane0[offset + j] |= byteImg0;
						Plane1[offset + j] &= byteMask;
						Plane1[offset + j] |= byteImg1;
					}
					else
					{
						mask++;											
						img0++;
						img1++;
					}
				}
				else
				{
					mask++;											
					img0++;
					img1++;
				}
			}
			if (j == width3)
			{
				if ((offset + j - ((Yscreen+i) * 30)) < CLIP_RIGHT)
				{
					if ((offset + j - ((Yscreen+i) * 30)) >= CLIP_LEFT)
					{
						if (shift)
						{
							byteMask = (*mask << (hmshift)) | (0xFF >> shift);
							byteImg0 = (*img0 << (hmshift));
							byteImg1 = (*img1 << (hmshift));
						}
						else
						{
							byteMask = *mask;
							byteImg0 = *img0;
							byteImg1 = *img1;
						}
						mask++;
						img0++;
						img1++;
						Plane0[offset + j] &= byteMask;
						Plane0[offset + j] |= byteImg0;
						Plane1[offset + j] &= byteMask;
						Plane1[offset + j] |= byteImg1;
					}
					else
					{
						mask++;											
						img0++;
						img1++;
					}
				}
				else
				{
					mask++;											
					img0++;
					img1++;
				}				
			}
		}
		else
		{
			mask+=width;
			img0+=width;
			img1+=width;
		}

		offset+=30;
	}
	
}


Les constantes CLIP_DOWN et CLIP_UP sont données en pixels et CLIP_LEFT et CLIP_RIGHT sont par pas de 8

Y'a t'il moyen de la faire (avec exactement le meme comportement) et qui soit plus perfomante (en asm ?) ?

Merci d'avance smile et pardon car y'a pas de commentaires tongue
Auteur de Mode7 Engine pour ti68k
Auteur de F-ZERO for TI68k
Membre de Orage Studio
Mon site perso : http://www.tigen.org/lionela/
Le gite de mes parents à coté de Narbonne :
http://chaletdenis.free.fr/

2

asm...

3

Huhu, ué ya moyen d'optimiser ça grin
Es tu sûr d'avoir réellement besoin du "X8" par contre ? (en fait, est-ce que tu connais à l'avance la taille des sprites ?)
Si tu peux t'en passer (éventuellement en codant plusieurs routines plus spécifiques), rien qu'en C ça permettrait déjà pas mal d'optimisations...
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

4

non désolé je ne connais pas la taille des sprites à l'avance : ca peut varier de 8 jusqu'à 144 (voire plus)... donc trop de routines a coder pour autant de tailles differentes.

Par contre je suis interéssé par toutes les optimisations possibles (et apparament tu en as smile)
Merci de m'aider
Auteur de Mode7 Engine pour ti68k
Auteur de F-ZERO for TI68k
Membre de Orage Studio
Mon site perso : http://www.tigen.org/lionela/
Le gite de mes parents à coté de Narbonne :
http://chaletdenis.free.fr/

5

hmm 144... C'est un peu grand alors le dessin ne doît pas toujours être optimal :/ (en particulier si tu as de larges zones de transparence...)
Comme optimisations, ben j'aurais vu le dessin en utilisant des words et des longs mais vu que c'est du X8, c'est inenvisageable...
En fait il ne reste que l'assembleur grin (Mais en assembleur cette routine est largement optimisable par rapport au C)
Tu devrais te pencher sur la programmation asm, écrire cette routine (c sûr ça serait pas optimisé au début mais tu peux toujours demander correction) serait un bon entraînement happy. (Si tu connais bien le C et le fonctionnement de la machine, apprendre l'assembleur n'est pas très long smile)
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

6

oui d'accord mais je me demande si ça vaut vraiment le coup de se mettre a l'assembleur sur un processeur obsolete comme le 68k ?

Je pense connaître assez bien le C et le fonctionnement des machines en général mais par contre je n'ai aucune notion sur les tricks utilisés pour optimiser une fonction comme celle là.
Au pire j'arriverais a réecrire la même routine en asm mais je suppose que gcc l'aura optimisée 10x plus que moi.

Déjà il y a la question : a68k ou gnu. (pas de troll ici please ^^)

Je prefere utiliser de l'asm inline car l'avenir de a68k dans tigcc est compromis et puis ce n'est que de la syntaxe, ca ne me dérange pas trop de taper des %.

que faut t'il savoir pour débuter : quel registres on a le droit de toucher, comment on accede aux données passées en param ? (il vaut peut être mieux que je mette toutes ces variables en global)

Voila j'aurais surement d'autres question mais si déja quelqu'un pouvait m'ecrire le tout début de la fonction ca me lancerait smile

Merci de votre patience
Auteur de Mode7 Engine pour ti68k
Auteur de F-ZERO for TI68k
Membre de Orage Studio
Mon site perso : http://www.tigen.org/lionela/
Le gite de mes parents à coté de Narbonne :
http://chaletdenis.free.fr/

7

je me demande si ça vaut vraiment le coup de se mettre a l'assembleur sur un processeur obsolete comme le 68k ?

pour apprendre la logique de base d'un langage ASM, pkoi pas...
la question que j'aurais plus tendance à me poser, c'est si ça vaut vraiment le coup de se mettre à un langage obsolète tongue
(enfin, franchement, c pas tous les jours que tu as besoin de coder en ASM... ça rend le développement beaucoup trop long... (même si sur des petites plates-formes, ou pour certains trucs très précis, ça peut être fort utile))
avatar
Tutorial C (TI-89/92+/v200) - Articles Développement Web (PHP, Javascript, ...)
« What is the sound of Perl? Is it not the sound of a wall that people have stopped banging their heads against? » - Larry Wall

8

9

aucun rapport ici, ce n'est pas pour programmer completement mais pour faire par exemple sa routine d'affichage de sprite.
et puis coder en asm n'accélère pas le developpement neutral

10

c'est si ça vaut vraiment le coup de se mettre à un langage obsolète
Heu attends, c'est pas obsolète l'assembleur 68k, hein. Déjà les 68k et dérivés (les µcontrôleurs CPU32 notamment) sont très répandus, probablement même les plus répandus dans l'industrie (quoique j'ai entendu dire que les 680x forment toujours une proportion non négligeable).
En plus les Coldfire ont une logique très similaire à la série des 68k, et donc savoir développer en asm pour 68k n'est pas perdu.

11

spectras
: Heu attends, c'est pas obsolète l'assembleur 68k, hein. Déjà les 68k et dérivés (les µcontrôleurs CPU32 notamment) sont très répandus, probablement même les plus répandus dans l'industrie (quoique j'ai entendu dire que les 680x forment toujours une proportion non négligeable).
Il me semble (mais je peux me tromper) que les CPU32 sont les deuxième plus répandus derrière ARM dans l'embarqué.
So much code to write, so little time.

12

Ok d'accord je veux bien m'y mettre, de toute façon j'ai déjà taté un peu de l'asm 68k mais je suis vraiment novice tongue
Sinon si l'un d'entre vous voulait bien m'écrire juste le debut de la routine pour que je puisse demarrer ce serait vraiment cool smile
Auteur de Mode7 Engine pour ti68k
Auteur de F-ZERO for TI68k
Membre de Orage Studio
Mon site perso : http://www.tigen.org/lionela/
Le gite de mes parents à coté de Narbonne :
http://chaletdenis.free.fr/

13

Allez s'il vous plait sad
Je sais qu'il y a des pro de l'asm parmi vous, ça doit vous prendre 2 min de m'écrire le debut de la routine (depilement etc...)
Auteur de Mode7 Engine pour ti68k
Auteur de F-ZERO for TI68k
Membre de Orage Studio
Mon site perso : http://www.tigen.org/lionela/
Le gite de mes parents à coté de Narbonne :
http://chaletdenis.free.fr/

14

Mais qu'est ce qu'il te manque exactement ? Le squelette d'une routine asm ?

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

15

Dépilement?! Le passage par registres, tu connais? smile

Et le squelette d'une routine ASM est:
.xdef foo
foo:
movem.l %d3-%d7/%a2-%a6,-(%a7)


movem.l (%a7)+,%d3-%d7/%a2-%a6
rts

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é

16

enfin ça dépend des fois hein ...
avatar
Que cache le pays des Dieux ? - Forum Ghibli - Forum Littéraire

La fin d'un monde souillé est venue. L'oiseau blanc plane dans le ciel annonçant le début d'une longue ère de purification. Détachons-nous à jamais de notre vie dans ce monde de souffrance. Ô toi l'oiseau blanc, l'être vêtu de bleu, guide nous vers ce monde de pureté. - Sutra originel dork.

17

(bien sûr, il est inutile de sauvegarder les registres que tu n'altères pas ^^)
[Cross]
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

18

Merci je vais essayer de commencer avec ça. par contre comment je l'integre dans le source en C ?
je met juste asm(" devant et ") derriere ?
Auteur de Mode7 Engine pour ti68k
Auteur de F-ZERO for TI68k
Membre de Orage Studio
Mon site perso : http://www.tigen.org/lionela/
Le gite de mes parents à coté de Narbonne :
http://chaletdenis.free.fr/

19

À mon avis, le mieux est de mettre ça dans un fichier .s.
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é

20

Je préfère les fichers .asm : le langage est plus lisible et très rapidement adaptable à GTC si tu as la bêta.
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.

21

22

Le probleme ne se pose pas, tant qu'a apprendre l'asm autant apprendre la syntaxe d'un assembleur non obsolète tongue
Et puis je voudrais tant que GTC oncalc puisse me compiler mon projet mais il fait une erreur à la compilation... (je l'ai signalée à Pollux mais vu qu'il ne me répond pas, je suppose qu'il n'a pas le temps (et je le comprend))
Auteur de Mode7 Engine pour ti68k
Auteur de F-ZERO for TI68k
Membre de Orage Studio
Mon site perso : http://www.tigen.org/lionela/
Le gite de mes parents à coté de Narbonne :
http://chaletdenis.free.fr/

23

lionelA :
je me demande si ça vaut vraiment le coup de se mettre a l'assembleur sur un processeur obsolete comme le 68k ?


Tu n'as rien à y perdre, A68k powaaaaaa !!!
Sincèrement.
Au pire j'arriverais a réecrire la même routine en asm mais je suppose que gcc l'aura optimisée 10x plus que moi.

Oui, GCC est super, mais ce n'est pas très difficile de faire mieux que lui avec un petit peu de logique et beaucoup de pratique

Déjà il y a la question : a68k ou gnu. (pas de troll ici please ^^)

J'ai commencé avec l'a68k, mais avec un peu de recul, la syntaxe de l'asm GNU me semble meilleure, surtout car elle permet des zones de commentaire avec /* et */
Je prefere utiliser de l'asm inline car l'avenir de a68k dans tigcc est compromis et puis ce n'est que de la syntaxe, ca ne me dérange pas trop de taper des %.

??? J'ai loupé un épisode là, depuis quand il est question que Ti-GCC ne gère plus l'a68k ?? Ou j'ai mal compris ?
que faut t'il savoir pour débuter : quel registres on a le droit de toucher, comment on accede aux données passées en param ? (il vaut peut être mieux que je mette toutes ces variables en global)

On peut tous les modifier, même a7 (pointeur de pile), mais faut faire attention aux conséquences...
Sinon, le passage des arguments par registre est plus efficace.

Remarque utile: il faut toujours considérer que les fonctions de l'OS détruisent les registres d0,d1,d2,a0,a1
Voila j'aurais surement d'autres question mais si déja quelqu'un pouvait m'ecrire le tout début de la fonction ca me lancerait smile

Je t'aiderais avec plaisir, mais j'ai trop de boulot en en MPSI... Désolé...
Mais il y a des programmeurs géniaux et très magnanimes sur ce forum qui se feront un plaisir de t'aider j'en suis sûr ^_^
Kevin Kofler
: À mon avis, le mieux est de mettre ça dans un fichier .s.


Entièrement d'accord, pour une fonction de cette importance, cela s'impose, et au moins tu as la coloration syntaxique.

De mon avis, tu ferais mieux par commencer à écrire en ASM des routines simples genre: repérer un pixel, afficher en NOIR & BLANC un sprite 8xh, puis 16xh, 24xh, 32xh, lxh, puis en effectuant un clipping sur l'écran, puis un clipping rectangulaire, puis après tu passes en niveaux de gris, puis tu arrives enfin à ta routine...
Beaucoup de travail en perspective, mais moins d'être génial, je doute que tu arrives à tes fins i.e. à dépasser le niveau d'optimisation de GCC de manière significative.
A tout hasard, je te donne un lien vers un de mes projets, je pense qu'il pourra t'aider, si tu passes assez de temps dessus pour comprendre la manière dont je traite le sujet des sprites.
Je n'ai pas fait de routine aussi générale que celle qui t'intéresse, je n'ai pas assez de temps... Mais je pense que ce que j'ai fait peut t'être utile.
http://membres.lycos.fr/tilotr/dl/LOTRlib.zip

Sinon bien sûr, confère-toi au guide de Jimmy Mardell, à la documentation de Zeljko, au tutorial de Kevin, à Google ton ami...

Pense aussi au self-modifing-code, au pré-calculé, à la distinction de cas remarquables, au passage d'adresses de fonctions en argument, c'est bien utile si l'on veut des fonctions générales, et peu encombrantes...

Dans un second temps:
Renseigne-toi aussi sur les différentes optimisations au niveau des instructions, par exemple
lea a(ax),ax s'optimise en addq.w #a,ax si a <= 8.
clr.l dx en moveq #0,dx
clr.l ax, en suba.l ax,ax
move.l ax,-(ax) en pea (ax)
move.b #-1,dx en st dx

et il y en a bôôôcoup d'autres...
regarde aussi les fonctions link, et unlink, pour créer des variables locales c'est très utile, notamment lorsque tu n'as plus de registre à ta disposition (au plus tu travailles avec des registres au plus c'est rapide)

AS produit déjà une bonne optimisation des instructions.

Dernier point: il n'est pas exclu qu' AS comporte encore des bogues, donc si tu es sûr de toi, n'hésite pas à aller embêter le mainteneur officiel (i.e.: Kevin) ^__^

Bonne chance et bon code !

[EDIT]: cf posts suivants.

24

JM_ :
move.l a0,-(ax) en pea (ax)
move.l ax,-(a7) plutôt smile
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. »

25

26

Erf, oui désolé...

27

Pour A68k dans TIGCC, il restera tant qu'il n'y a pas d'autre solution pour compiler les programmes existants. Je compte rendre GNU as compatible avec la syntaxe A68k (avec un switch), mais je n'ai pas encore commencé ce travail.
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é

28

lionelA :
Le probleme ne se pose pas, tant qu'a apprendre l'asm autant apprendre la syntaxe d'un assembleur non obsolète tongue
Et puis je voudrais tant que GTC oncalc puisse me compiler mon projet mais il fait une erreur à la compilation... (je l'ai signalée à Pollux mais vu qu'il ne me répond pas, je suppose qu'il n'a pas le temps (et je le comprend))

Ah oui tiens j'avais commencé à y répondre mais j'avais pas dû envoyer le mini-msg en fait, désolé triso
Si je me souviens bien, le premier pb est que tu inclus tigcclib.h plusieurs fois (et il n'y avait pas de protection contre, je l'ai rajoutée juste après ton bug report), et ensuite tu utilises des floats mais leur support n'est pas encore fini dans GTC (j'avais commencé avec ma lib de floats FFP et ça marchait à peu près, mais le support BCD [i.e. celui du TIOS] est encore incomplet)
JM_
:
Déjà il y a la question : a68k ou gnu. (pas de troll ici please ^^)
J'ai commencé avec l'a68k, mais avec un peu de recul, la syntaxe de l'asm GNU me semble meilleure, surtout car elle permet des zones de commentaire avec /* et */

Bof, c pas franchement indispensable (en tout cas bien moins que les labels locaux), si tu veux commenter une région de code tu as plusieurs solutions :
- ifeq 0 dans a68k
- /* */ marche aussi si tu utilises GTC
De mon avis, tu ferais mieux par commencer à écrire en ASM des routines simples genre: repérer un pixel, afficher en NOIR & BLANC un sprite 8xh, puis 16xh, 24xh, 32xh, lxh, puis en effectuant un clipping sur l'écran, puis un clipping rectangulaire, puis après tu passes en niveaux de gris, puis tu arrives enfin à ta routine... Beaucoup de travail en perspective, mais moins d'être génial, je doute que tu arrives à tes fins i.e. à dépasser le niveau d'optimisation de GCC de manière significative.

Ce n'est pas si difficile qu'on pourrait le croire si on maîtrise bien tous les concepts du C (pointeurs...), et en tout cas quand bien même tu ne connaîtrais pas toutes les astuces, ça te permet au moins de voir clairement ce qui est en trop, et ça te permet d'optimiser ton code C en conséquence. Franchement, ça n'est jamais inutile. Et après, tu peux lire (à défaut d'écrire) d'autres langages assembleur sans trop trop de pb...
Sinon bien sûr, confère-toi au guide de Jimmy Mardell, à la documentation de Zeljko, au tutorial de Kevin, à Google ton ami...

Le guide de Jimmy Mardell est très bien, vi ^^
Pense aussi au self-modifing-code, au pré-calculé, à la distinction de cas remarquables, au passage d'adresses de fonctions en argument, c'est bien utile si l'on veut des fonctions générales, et peu encombrantes...

Le self-modifying code, on en fait tout un fromage, mais franchement, c'est très très secondaire. Ca demande de connaître un peu les détails du codage de chaque instruction, ce qui n'est vraiment pas du tout nécessaire pour bien programmer en assembleur. Ca peut permettre dans certains cas de grapiller qques cycles/octets, mais bon c pas fondamental... (on peut parfaitement considérer qu'on fait comme si le code était en ROM et puis voilà)

Le pré-calcul, par contre, là c'est fondamental, pareil pour distinguer des cas importants, et d'ailleurs on les retrouve aussi dans le C, donc c important pour bien optimiser. Finalement, l'asm ne change pas grand-chose, ça permet juste de bien mesurer le gain apporté par des optimisations et comprendre d'où il vient.
Dans un second temps:
Renseigne-toi aussi sur les différentes optimisations au niveau des instructions, par exemple
lea a(ax),ax s'optimise en addq.w #a,ax si a <= 8.
clr.l dx en moveq #0,dx
clr.l ax, en suba.l ax,ax
move.l ax,-(ax) en pea (ax)
move.b #-1,dx en st dx
et il y en a bôôôcoup d'autres...

Plus simplement : à chaque fois que tu écris du code, regarde combien de cycles et d'octets chaque instruction prend... Après, le reste viendra "naturellement"
regarde aussi les fonctions link, et unlink, pour créer des variables locales c'est très utile, notamment lorsque tu n'as plus de registre à ta disposition (au plus tu travailles avec des registres au plus c'est rapide)

Euh franchement c pas indispensable non plus, sauf si tu veux l'optimisation en taille à tout prix (-2 octets contre une grosse pénalité en vitesse) ou que tu fais plein de alloca() de taille variable, subq #foo,a7 et addq #foo,a7 marchent tout aussi bien (et en fait si ça se trouve tu n'en auras même pas besoin)
AS produit déjà une bonne optimisation des instructions.

Il ne faut pas considérer ça comme une optimisation, c'est juste qu'il (enfin, a68k, gtc et as-de-nitro aussi) accepte plusieurs écritures pour la même instruction...

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

29

Pollux
: - ifeq 0 dans a68k

Plutôt ifne 0. smile
AS produit déjà une bonne optimisation des instructions.
Il ne faut pas considérer ça comme une optimisation, c'est juste qu'il (enfin, a68k, gtc et as-de-nitro aussi) accepte plusieurs écritures pour la même instruction...

Je n'appelle pas vraiment changer lea 8(a7),a7 en addq.l #8,a7 "accepter plusieurs écritures pour la même instruction".
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é

30

Kevin Kofler
:
Pollux
: - ifeq 0 dans a68k

Plutôt ifne 0. smile

Oué bon, tout le monde avait compris #mac# cheeky
AS produit déjà une bonne optimisation des instructions.
Il ne faut pas considérer ça comme une optimisation, c'est juste qu'il (enfin, a68k, gtc et as-de-nitro aussi) accepte plusieurs écritures pour la même instruction...

Je n'appelle pas vraiment changer lea 8(a7),a7 en addq.l #8,a7 "accepter plusieurs écritures pour la même instruction".

Bah moralement si, si tu ne considères pas le mot "instruction" au sens strict ^^ (i.e. que t'as ràf de la représentation mémoire) L'intérêt, c'est surtout de pouvoir changer des constantes entières sans casser du code...

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