nesquick - Page 4

Nyall> I saw your old sig this morning and was surprised while checking your mail that you actually were you, and here

Sinon, de manière plus général, en ce qui concerne l'optimisation d'instructions simples, cf http://oldwww.nvg.ntnu.no/amiga/MC680x0_Sections/optimizations.HTML , y'en a pas mal.

Kevin Kofler
:

Godzil :
pour le move.b dn,-(a7)
je ne trouve pas d'info comme quoi en realité a7 serait décrémenté de 2 au lieu de 1

Tu n'as pas bien cherché alors.

Si j'ai cherché et pas dans une seule doc (et je cherche que dans les docs officielles hein !)

PAS UN SEUL MOT sur le fait qu'un prédrémentation/postincrémentation sur le registre a7 (ou USP ou SSP) se passe de maniere DIFFERENTE qu'avec les autres registre d'addresse

PAS UN MOT meme sur la doc OFFICIELLE de Motorola (j'ai la 9ème edition imprimé sous la main et je l'ai parcourue de fond en comble)

en plus le code move.b dn,-(an) n'est pas spécifique a a7.

Mais a7 est traîté spécialement par le processeur.

Oui et non

Non il est utilise comme un registre d'adresse normal

Oui pasqu'il est spécial dans le sens ou en fait il est "double" (SSP/USP)

non je suis désolé (cf mon livre sur le 68000) :

Addressage indirect Prédécrémenté

Le registre d'addresse An contienu une addresse mémoire. Cette addresse doit être décrémenté de N pour donner l'addresse de l'opérande.
N = 1 si l'opérande est un octet
N = 2 si l'opérande est un mot
N = 4 si l'opérand est un mot double
An = An - N et AE = (An)

Jette ton livre alors. Le 68kguide donne la bonne information.

Jette ton guide alors. Qui l'a écrit d'ailleurs ? J'aimerait que tu ai un peu plus de respect envers les gens qui écrivent les livres (surtout que ce livre, même si il est pas la doc officielle de motorola, à été écrit en collaboration avec motorola)

Et la documentation OFFICIELLE de motorola ne fait pas fi de ce genre de choses

A la limite que le livre (ou la doc) de motorola ne parle pas du pipeline du processeur je peut comprendre étant donnée que cela n'a pas d'incidence directe sur l'état de la mémoire et la manière de programmer le processeur, mais sachant quel impact aurait cette particularité si a7 était traité de manière différentes (aka pas de .b pour un -(a7) ou (a7)+) change complètement le resultat.

Surtout que l'opcode

  00 01 111 100  xxx xxx
  M  T   D    D
  o  a   s    s
  v  i   t    t
  e  l   R    M
     l   e    o
     e   g    d
              e

Par exemple

0b00 01 111 100 000 000

soit 1F00 ( move.b d0,-(a7) )

fait partit des opcodes VALIDE du 68000

je te laisse imaginer un cas d'une abération si le 68000 considerais le move.b xx,-(a7) (ou tjrs pareil hein (a7)+) comme un move.w :

d0.b = 0xFF
d1.b = 0x3F
on pose le code suivant :

move.b d0, -(a7)
move.b d1, -(a7)
move.w (a7)+, d0

On s'attend a avoir d0.w = 0x3FFF ce qui est logique d'ailleurs avoir autre chose serait une abbération et un BUG !

 ScanKbd:				; keyScan par ExtendeD (modified)

	moveq.l	#9,d0
	moveq.l	#-2,d2
	movea.l	#$600018,a0

 SaveRow:

	move.w	d2,(a0)
	moveq.l	#11,d1			; d1=0

 WaitKeys:

	dbra.s	d1,WaitKeys		; copy the ports to a virtual keybord table

	move.b	3(a0),-(a7)		; a7 will we incremented of 2 !!
	rol.w	#1,d2
	dbra.s	d0,SaveRow

	lea.l	20(a7),a7		; restore the stack

C'est le code que j'utilise dans mes fonctions de type getkey, et a7 est bien prédécrémenté de 2. Après vérification au débuger, le code généré comporte effectivement ce qui est inscrit. A7 est traité différemment pour de simples raisons techniques.

Godzil
: Si j'ai cherché et pas dans une seule doc (et je cherche que dans les docs officielles hein !)

Tes docs officielles, tu peux te les fourrer tu sais où... Les docs officielles sont souvent les moins bonnes.

Jette ton guide alors. Qui l'a écrit d'ailleurs ?

Jimmy Mårdell. Ce n'est pas n'importe qui. Et je suppose qu'il a essayé, lui...

J'aimerait que tu ai un peu plus de respect envers les gens qui écrivent les livres

J'aimerais que tu aies un peu plus de respect envers les vrais programmeurs qui écrivent les vraies documentations.

Pas un pour rattraper l'autre entre Kevin et Godzil...

Godzil> Je te ferais remarquer qu'au post ./70 je cite la doc officielle de Motorola (le 68KPM.pdf).

godzil > arrete de faire ton Thibaut (on ne va pas demander à Kevin de ne pas faire son Kevin ^^)

c rigolo cette discussion

mais ça serait encore plus rigolo de revenir au sujet...

Retour au sujet donc:
nouveau topic ouvert dans le forum international, ici

Ximoon :

 ScanKbd:				; keyScan par ExtendeD (modified)

	moveq.l	#9,d0
	moveq.l	#-2,d2
	movea.l	#$600018,a0

 SaveRow:

	move.w	d2,(a0)
	moveq.l	#11,d1			; d1=0

 WaitKeys:

	dbra.s	d1,WaitKeys		; copy the ports to a virtual keybord table

	move.b	3(a0),-(a7)		; a7 will we incremented of 2 !!
	rol.w	#1,d2
	dbra.s	d0,SaveRow

	lea.l	20(a7),a7		; restore the stack

C'est le code que j'utilise dans mes fonctions de type getkey, et a7 est bien prédécrémenté de 2. Après vérification au débuger, le code généré comporte effectivement ce qui est inscrit. A7 est traité différemment pour de simples raisons techniques.

Sa n'empeche que ça reste une abération

ben nan, c parfaitement documenté et ça permet des optimisations sympa

non c'est un bug qu'il on documenté apres coup


move.B xx,-(a7)

c'est pas la meme chose que

move.w xx,-(a7)


d'ailleur j'ai peur qu'il faille se méfier car les 68k > ne provoquent plus d'addresse erreur sur un accé a une addresse impaire

la stack n'est pas manipulable a des adresses impaires, c'est tout.
Mais autant en profiter comme une feature

(godzil, les à longueur de posts, c'est pas top, je trouve :/)

Nil: :/

désolé :/

j'suis pas trop d"humeur "" "" ces derniers temps

Non, c'est logique, si un octet seul est empilé et qu'une interruption se déclenche, c'est foutu.

Non puisque l'USP est utilisée.

Pourquoi je dis une it moi... Si une instruction de branchement est utilisée après napu vala.

boah, c pas vraiment une justification : tu peux forcer a7 à prendre une valeur impaire, ça va aussi faire foire les instructions de branchement... Par contre ça permet de passer efficacement des "char" à une fonction C par la pile (à condition que la convention de passage soit fait pour, ce qui n'est pas le cas sur TI ^^), et qques autres astuces...

Enfin ça reste assez gore... Et sur 68000 à part des optimisations très tordues ça change pas grand chose de passer un char quand on peut empiler un short

Bah si : fonction(*ptr), par exemple...

Pollux :
boah, c pas vraiment une justification : tu peux forcer a7 à prendre une valeur impaire, ça va aussi faire foire les instructions de branchement... Par contre ça permet de passer efficacement des "char" à une fonction C par la pile (à condition que la convention de passage soit fait pour, ce qui n'est pas le cas sur TI ^^), et qques autres astuces...

tu es sûr qu'on peut forcer a7 à avoir une adresse impaire ? je ne crois pas (au moins en superviseur)

Je pense qu'un addq.w #1,a7 permet de lui donner une valeur impaire.

Que donne http://yn1.free.fr/up/plop.89z sur vraie calc ?

EDIT : et puis http://yn1.free.fr/up/plop2.89z au cas où