Stratégie registeresque et autres habitudes - Page 4

90

Le 28/10/2007 à 00:00

(dsl pour les erreurs, j'ai pas fait du 68k depuis des lustres

)

91

Le 28/10/2007 à 00:11

Thibaut (./83) :
Le deuxième paragraphe en langage humain, ça donne quoi ?

La région jaune est plus grande que la région hachurée :
NeFm

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

Effectivement, la seule manière que je vois pour écrire un éditeur de textes en C en un après-midi, c'est d'utiliser les fonctions TE_*, mais du coup ça n'apporte rien par rapport à l'éditeur de textes intégré, parce que toutes ses limitations (y compris la lenteur) viennent de ces fonctions.

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é

94

95

Le 28/10/2007 à 08:32

Pollux : Je vois

Beau graphique !

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.

96

Le 28/10/2007 à 15:00

et avec du code auto modifié dans ce genre ?

	xdef _ti89
	xdef _nostub
		
	

; ---------------------------------
	
BSRS	MACRO ; func,retFunc
	move.b	#(\@suiteDuCode-\2-2),\2+1
	bra.s	\1
\@suiteDuCode:
	ENDM

RTSS	MACRO ; retFunc
\1	bra.s	*
	ENDM




BSRW	MACRO ; func,retFunc
	move.w	#(\@suiteDuCode-\2-2),\2+2
	bra.w	\1
\@suiteDuCode:
	ENDM
	

RTSW	MACRO ; retFunc
\1	bra.w	*+$FFE	; pour contrer l'optim forcée de bra.w * vers bra.s * avec les switchs par défaut #grrrr#
	ENDM
	
	
; ---------------------------------
	
	
	
	
_ti89:
_nostub:
;	bra.s	*
	BSRS func1,retFunc1
	BSRW func2,retFunc2
	rts





	ds.l	10
func1:
	move.l	#-1,($4c00+50*30+8).w
	RTSS	retFunc1




	ds.b	300
func2:
	move.l	#$FF00FF00,($4c00+49*30+8).w
	move.l	#$00FF00FF,($4c00+50*30+8).w
	move.l	#$FF00FF00,($4c00+51*30+8).w
	RTSW	retFunc2



END

Ça ne bouffe pas de registre du tout, et ça se contente d'un accès mémoire en écriture, ça devrait être mieux qu'un bsr+rts non ?

(à priori ça fonctionne, mais vu mes souvenirs, ça demande à être vérifié

)

PS : par contre ça modifie les flags à cause du move, alors que bsr ne modifie rien...

97

Le 28/10/2007 à 15:09

Je crois qu'on fait difficilement plus crado, mais c'est ingénieux

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.

98

Le 28/10/2007 à 15:28

bra.w avec un .w explicit n'est plus optimisé en bra.s depuis TIGCC 0.96 Beta 1.

99

Le 28/10/2007 à 16:00

Pen^2 (./96) :
Ça ne bouffe pas de registre du tout, et ça se contente d'un accès mémoire en écriture, ça devrait être mieux qu'un bsr+rts non ?
(à priori ça fonctionne, mais vu mes souvenirs, ça demande à être vérifié )

Malheureusement non : tu dois lire un mot supplémentaire pour connaître \@suiteDuCode, et au moins un autre pour connaître \2+2 (en supposant qu'il n'y a pas de relogement) ; du coup rien que le move.w prend 16 cycles, ce qui fait que ton appel est 2 cycles plus lent qu'un bsr+rts ^^ Bref, le code auto-modifié c'est généralement rentable que quand on exécute plusieurs fois le code modifié...

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

100

Le 29/10/2007 à 00:25

Kevin Kofler (./98) :
bra.w avec un .w explicit n'est plus optimisé en bra.s depuis TIGCC 0.96 Beta 1.

101

Le 29/10/2007 à 00:51

Pollux (./99) :
Pen^2 (./96) :
Ça ne bouffe pas de registre du tout, et ça se contente d'un accès mémoire en écriture, ça devrait être mieux qu'un bsr+rts non ?
(à priori ça fonctionne, mais vu mes souvenirs, ça demande à être vérifié )
Malheureusement non : tu dois lire un mot supplémentaire pour connaître \@suiteDuCode, et au moins un autre pour connaître \2+2 (en supposant qu'il n'y a pas de relogement) ; du coup rien que le move.w prend 16 cycles, ce qui fait que ton appel est 2 cycles plus lent qu'un bsr+rts ^^

bon, c'est peut être plus gros et plus lent, mais au moins c'est bien plus élégant

(ah, non, même pas ?

)

Thibaut (./97) :
Je crois qu'on fait difficilement plus crado

Pollux (./99) :
Bref, le code auto-modifié c'est généralement rentable que quand on exécute plusieurs fois le code modifié...

qu'à cela ne tienne ! (attention, combo pour les deux cites !)

	xdef _ti89
	xdef _nostub
		
	

; ---------------------------------
	
BSRS	MACRO ; func,retFunc
	move.b	#(\@suiteDuCode-\2-2),\2+1
	bra.s	\1
\@suiteDuCode:
	ENDM

RTSS	MACRO ; retFunc
\1	bra.s	*
	ENDM




BSRW	MACRO ; func,retFunc
	move.w	#(\@suiteDuCode-\2-2),\2+2
	bra.w	\1
\@suiteDuCode:
	ENDM
	

RTSW	MACRO ; retFunc
\1	bra.w	*+$FFE	; pour contrer l'optim forcée de bra.w * vers bra.s * avec les switchs par défaut de TIGCC<0.96 Beta 1
	ENDM
	
	
; ---------------------------------
	
	
	
	
_ti89:
_nostub:
	;bra.s	*
	move.l	d0,-(a7)

	moveq	#-1,d0
	BSRS	func1,retFunc1
	dbf	d0,*-2
	BSRW	func2,retFunc2
	dbf	d0,*-4

	move.l	(a7)+,d0
	rts





	ds.l	10
func1:
	move.l	#-1,($4c00+50*30+8).w
	RTSS	retFunc1




	ds.b	300
func2:
	move.l	#$FF00FF00,($4c00+49*30+8).w
	move.l	#$00FF00FF,($4c00+50*30+8).w
	move.l	#$FF00FF00,($4c00+51*30+8).w
	RTSW	retFunc2



END

muhahahaha

(

²)