fonction fopen : petit bug dans une implémentation ASM optimisée :( - Page 1

Je n''arrive pas à corriger un dernier bug qui apparaît avec les fichiers textes, dans mon implémentation de fopen
En laissant addq.l #3,a2 les fichiers prennent une taille "aléatoire", et le type est EXPR.
Si j'écris addq.l #2,a2 les pb de taille et de type sont réglés, mais le premier octet du fichier n'est pas écrit (ce dernier point est normal...).
J'ai signalé la ligne qui correspond au phénomène.

Si un génie passe par là

void @fopen[byte @Nom, @Mode]
<
fopen:
 move.l  4(a7),a0
 move.l  8(a7),a1
 movem.l d3-d5/a2/a3,-(a7)
 
 move.b  -(a0),fopen_byte
 clr.b   (a0)+
fopen_copienom_loop:
 tst.b   (a0)+
 bne.s   fopen_copienom_loop
 pea     -1(a0)
 
 moveq   #0,d3          ; flags
 moveq   #0,d4          ; pas append
 moveq   #0,d5          ; pas mode r+
 move.b  (a1)+,d0
 cmp.b   #'w',d0
 beq.s   fopen_modeW
 cmp.b   #'r',d0
 beq.s   fopen_modeR
 cmp.b   #'a',d0
 bne     fopen_erreur
fopen_modeA:
 moveq   #-1,d4         ; append
fopen_modeW:
 move.w  #$0002,d3
 bra.s   fopen_modesSuite
fopen_modeR:
 move.w  #$0001,d3
fopen_modesSuite:
 move.b  (a1)+,d0
 cmp.b   #'b',d0
 beq.s   fopen_modeB
 cmp.b   #'t',d0
 beq.s   fopen_modesSuite
 cmp.b   #'+',d0
 bne.s   fopen_tests_fin
fopen_modeP:
 btst.b  #0,d3
 sne     d5
 or.w    #$0003,d3
 bra.s   fopen_modesSuite
fopen_modeB:
 or.w    #$0040,d3
 bra.s   fopen_modesSuite
 
fopen_tests_fin:
 tst.w   d4
 beq.s   fopen_pasappend
 move.l  $180(a6),a0    ; SymFind
 jsr     (a0)
 tst.l   d0
 bne.s   fopen_dejacherche
 bra.s   fopen_ecraser
fopen_pasappend:
 btst.l  #1,d3
 beq.s   fopen_pascreer
 tst.b   d5
 bne.s   fopen_pascreer
fopen_ecraser:
 move.l  $170(a6),a0    ; SymAdd
 jsr     (a0)
 move.l  d0,(a7)
 beq     fopen_erreur
 move.l  $1E4(a6),a0    ; DerefSym
 jsr     (a0)
 move.l  a0,a2
 move.l  #8,(a7)
 move.l  $240(a6),a0    ; HeapAlloc
 jsr     (a0)
 move.w  d0,(a7)
 beq     fopen_erreur
 move.w  d0,12(a2)
 move.l  $258(a6),a0    ; HeapDeref
 jsr     (a0)
 move.w  #2,(a0)
 btst.l  #6,d3
 bne.s   fopen_suite
 addq.w  #3,(a0)
 move.l  #$00012000,2(a0)
 move.b  #$E0,6(a0)
 bra.s   fopen_suite
fopen_pascreer:
 move.l  $180(a6),a0    ; SymFind
 jsr     (a0)
fopen_dejacherche:
 move.l  d0,(a7)
 beq.s   fopen_erreur
 move.l  $1E4(a6),a0    ; DerefSym
 jsr     (a0)
 move.w  12(a0),(a7)
 move.l  $258(a6),a0    ; HeapDeref
 jsr     (a0)
fopen_suite:
 move.l  a0,a2
 pea     18
 move.l  $288(a6),a0    ; HeapAllocPtr
 jsr     (a0)
 addq.l  #4,a7
 move.l  a0,a3
 beq.s   fopen_erreur
 move.l  $268(a6),a0    ; HeapLock
 jsr     (a0)
 move.w  d3,10(a3)
 clr.w   12(a3)
 move.l  a2,4(a3)
 move.w  (a7),8(a3)
 clr.l   14(a3)
 move.w  (a2),16(a3)
 addq.w  #2,16(a3)
 tst.b   d4
 beq.s   fopen_posdebut
 move.w  (a2),d0
 lea     0(a2,d0.w),a2
 move.l  a2,(a3)
 bra.s   fopen_fin
fopen_posdebut:
 btst.l  #6,d3
 bne.s   fopen_binaire
 addq.l  #3,a2               ; ==== ICI ====
fopen_binaire:
 addq.l  #2,a2
 move.l  a2,(a3)
 bra.s   fopen_fin
fopen_erreur:
 sub.w   a3,a3
fopen_fin:
 move.l  a3,a0
 addq.l  #4,a7
 movem.l (a7)+,d3-d5/a2/a3
 move.l  4(a7),a1
 move.b  fopen_byte(pc),-1(a1)
 rts
fopen_byte:
 dc.w    0
>

ATTENTION pour essayer sous TIGCC, remplacez tous les a6 par a5 et activez OPTIMIZE_ROM_CALL.

totally nostub ?

Azur is TOTALLY _nostub
But if you assemble the file ouptuted by the Azur compiler with an assembler which support kernel relocation tables, and if you write a library with the aim of call kernel libraries instead of TIOS and Azur library functions, you can build kernel programs perfectly !!

(heu bon j'ai 8/20 en anglais : faut pas m'en demander trop)
[edit]Edité par Thibaut le 13-12-2001 à 15:13:25[/edit]

Bon, on est gentil, et on teste ça en compilant avec A68k et en passant dans VTI le suivant:

 include "OS.h"
 xdef _nostub
 xdef _ti89
 xdef _ti92plus

 movem.l d0-d7/a0-a6,-(a7)
 move.l $c8,a6
 pea.l wb(PC)
 pea.l fichier(PC)
 bsr fopen
 addq.l #8,a7
 movem.l (a7)+,d0-d7/a0-a6
 rts

wb: dc.b 'wb',0
fichier: dc.b 'foobar',0

suivi de ton code.

Résultats à bientôt.

Déjà, il y a un problème avec le mode binaire: le word de taille à l'origine devrait être 0, pas 2. (move.w #2,(a0) dans fopen_ecraser devrait être clr.w(a0).) Mais comme ton intruction n'a l'air d'être exécutée qu'en mode texte, j'essaye le mode 'wt' maintenant.

Erreur catastrophique: dans fopen_suite, le HeapLock du bloc du fichier doit passer devant HeapAllocPtr, sinon, la réorganisation de la RAM rend invalide a2. Bon, je redébogue en corrigeant a2 dans le débogueur pour voir ce que ça donne. Mais je pense que le problème est soit ce que je viens de voir (la prochaine fonction de fichiers écrira n'importe où), soit la même erreur que pour le mode binaire (le move.w #2,(a0) incriminé est exécuté pour les 2 modes - mais je pense que 5 est bien la taille résultante correcte et que tu devras changer addq.w #3,(a0) en addq.w #5,(a0) pour le mode texte si tu corriges le mode binaire).
[edit]Edité par Kevin Kofler le 13-12-2001 à 06:18:57[/edit]

Oui, mis à part ce problème (grave), le mode texte a l'air de marcher très bien. Donc:
- pour corriger le mode binaire:

  move.w  d0,(a7)
  beq     fopen_erreur
  move.w  d0,12(a2)
  move.l  $258(a6),a0    ; HeapDeref
  jsr     (a0)
- move.w  #2,(a0)
+ clr.w (a0)
  btst.l  #6,d3
  bne.s   fopen_suite
- addq.w  #3,(a0)
+ addq.w #5,(a0)
  move.l  #$00012000,2(a0)
  move.b  #$E0,6(a0)
  bra.s   fopen_suite
 fopen_pascreer:

et pour corriger ton problème principal:

  move.w  12(a0),(a7)
  move.l  $258(a6),a0    ; HeapDeref
  jsr     (a0)
 fopen_suite:
  move.l  a0,a2
+ move.l  $268(a6),a0    ; HeapLock
+ jsr     (a0)
  pea     18
  move.l  $288(a6),a0    ; HeapAllocPtr
  jsr     (a0)
  addq.l  #4,a7
  move.l  a0,a3
- beq.s   fopen_erreur
+ beq.s   fopen_erreur_unlock
- move.l  $268(a6),a0    ; HeapLock
- jsr     (a0)
  move.w  d3,10(a3)
  clr.w   12(a3)
  move.l  a2,4(a3)
  move.w  (a7),8(a3)
  clr.l   14(a3)
  move.w  (a2),16(a3)
  addq.w  #2,16(a3)
  tst.b   d4
  beq.s   fopen_posdebut
  move.w  (a2),d0
  lea     0(a2,d0.w),a2
  move.l  a2,(a3)
  bra.s   fopen_fin
 fopen_posdebut:
  btst.l  #6,d3
  bne.s   fopen_binaire
- addq.l  #3,a2               ; ==== ICI ====
+ addq.l  #3,a2               ; Le problème n'est probablement pas là.
 fopen_binaire:
  addq.l  #2,a2
  move.l  a2,(a3)
  bra.s   fopen_fin
+fopen_erreur_unlock:
+ move.l  $27c(a6),a0    ; HeapUnlock ($9f*4=$27c)
+ jsr     (a0)
 fopen_erreur:
  sub.w   a3,a3
 fopen_fin:
  move.l  a3,a0
  addq.l  #4,a7

Ça devrait être bon là.

Il me semblait avoir observé que les expressions vides présentaient $0002 comme taille sur les 2 premiers octets

>> la réorganisation de la RAM
Je ne savais pas que HeapLock réorganisait la RAM, merci

Sinon, tu en penses quoi de mon anglais (je viens de corriger des fautes dans mon post)
Pour ton français : on ne dit pas "Résultats à bientôt" mais "Résultats bientôt"

Au fait, tu sais que les fonctions d'écriture de TIGCClib réallouent les fichiers par palliers de 1000 octets (je trouve que 500 auraient suffit, avis personnel).
Il se trouve que fclose se contente de délocker le segment de données des fichiers, sans les redimensionner.
Ainsi on perd dans le pire des cas 999 octets de RAM par fichier traité !

C'est un oubli ou un choix de Z.J. ?

>Thibaut:
>Sinon, tu en penses quoi de mon anglais (je viens de corriger des fautes dans mon post)
>But if you assemble the file ouptuted by the Azur compiler with an assembler which support kernel relocation tables, and if you write a library with the aim of call kernel libraries instead of TIOS and Azur library functions, you can build kernel programs perfectly !!

Ça va plus ou moins. auf qu'on dit "the aim of calling". Et que je pense que le participe passé de output est tout simplement output.

>Je ne savais pas que HeapLock réorganisait la RAM, merci

Pas HeapLock. C'est HeapAllocPtr qui réorganise la RAM.

>Au fait, tu sais que les fonctions d'écriture de TIGCClib réallouent les fichiers par palliers de 1000 octets (je trouve que 500 auraient suffit, avis personnel).
>Il se trouve que fclose se contente de délocker le segment de données des fichiers, sans les redimensionner.
>Ainsi on perd dans le pire des cas 999 octets de RAM par fichier traité !
>C'est un oubli ou un choix de Z.J. ?

C'est plutôt un oubli, connu depuis quelque temps, mais Zeljko n'a pas le temps de le corriger. Je vais voir ce que je peux faire (ça ne doit pas être dur à corriger). Ou alors tu nous envoies tes routines avec la permission de les intégrer dans TIGCCLIB.
[edit]Edité par Kevin Kofler le 13-12-2001 à 17:40:30[/edit]

Aucun pb, je peux vous envoyer mon fopen (moins gros et plus rapide que la version de TIGCClib) quand le déboguage sera fini, mon rename (avec TIGCClib cette fonction efface le fichier NewName s'il existe déjà... plutôt débile) et mon fclose (qui corrige donc le bug dont nous venons de parler).

Thibaut> cool !
Des nouvelles fonctions, et moins buggées, en plus !!!
Et qui prennent moins de mémoire, pour fopen !

Merci de la part des programmeurs C.

>". Et que je pense que le participe passé de output est tout simplement output. "

En tout cas, ce n'est pas ouptuted

> Thibaut :
Le lien de ta signature ne correspond pas Ah pardon, c'est voulu

squale92 : Tu as déjà eu le temps d'en parler à tous les programmeurs C ! Chapeau
[edit]Edité par Thibaut le 13-12-2001 à 17:58:32[/edit]

je suis un programmeur C => réprésntatif d'une infime partie des programmeurs C !
de plus, je doute que bcp de programmeurs soient assez bête pour en vouloir à l'auteur d'une fonction moins gourmande en mémoire, et qui ne soient pas bugguée !!!

ouais, c'est bien pour nous...

Et voila : u programmeur qui est d'accord avec moi !

Pour rename, je me demande si ce n'est pas fait exprès pour respecter le standard ANSI.

oué, ben, dans ce cas, pourquoi ne pas fiare rename_2, ou quelque chose d'approchant ?
le standar ANSI, c'est biean bo... mais y'a des cas où c pas vraiment applicable à une TI
(cf fonction scanf, par exemple)

Il faudra que je reprenne mon début de sscanf. Du scanning d'expressions quelconques en 1 ou 2 KO (estimation à partir de ce que j'ai - j'espère que ça ne deviendra pas plus que ça), ce n'est déjà pas mal, si on considère les tailles (approximatives) d'autres routines couramment utilisées:
- h220xTSR - 2/3 KO
- tables de sinus et/ou cosinus - 1/2 KO - 1 KO
- niveaux de gris - 1 KO
- décompression ExePack - 3/2 KO
- kernel - 3 KO - 25/2 KO
- librairies dynamiques communément utilisées: 5 KO - 20 KO
- AMS: 1300 KO

arf...
oué... 1 ou 2ko...
Ben, pour ce prix là, je v me contenter de ma version modifiée de InputStr (transformée en InputStrXY) de la FAQ de TIGCC, couplée avec une paire de fonctions de conversion...

héhé squale92 )

Kevin ça marche toujours pas

Les fichiers sont créés correctement, mais dès qu'on écrit quelque chose dedans, le type devient EXPR et la taille reste 7 (en mode texte du moins). En modifiant la ligne indiquée, tout rentre dans l'ordre, mais le premier octet n'est pas écrit (enfin si, mais à la place du $20 qui sert pour les commandes)... Bref toujours le même bug.

Je te file la version TIGCC avec le prototype pour que tu puisses tester avec TIGCC (remplissage avec printf, etc...) :

extern FILE *fopen2(char *Nom, char *Mode);



fopen2:			; FILE *(char *Nom, char *Mode)
	move.l		4(a7),a0
	move.l		8(a7),a1
	movem.l		d3-d5/a2/a3,-(a7)
	
	move.b		-(a0),fopen2_byte
	clr.b		(a0)+
fopen2_loop:
	tst.b		(a0)+
	bne.s		fopen2_loop
	pea		-1(a0)
	
	moveq		#0,d3			; flags
	moveq		#0,d4			; pas append
	moveq		#0,d5			; pas mode r+
	move.b		(a1)+,d0
	cmp.b		#'w',d0
	beq.s		fopen2_modeW
	cmp.b		#'r',d0
	beq.s		fopen2_modeR
	cmp.b		#'a',d0
	bne		fopen2_erreur
fopen2_modeA:
	moveq		#-1,d4			; append
fopen2_modeW:
	move.w		#$0002,d3
	bra.s		fopen2_modesSuite
fopen2_modeR:
	move.w		#$0001,d3
fopen2_modesSuite:
	move.b		(a1)+,d0
	cmp.b		#'b',d0
	beq.s		fopen2_modeB
	cmp.b		#'t',d0
	beq.s		fopen2_modesSuite
	cmp.b		#'+',d0
	bne.s		fopen2_tests_fin
fopen2_modeP:
	btst.b		#0,d3
	sne		d5
	or.w		#$0003,d3
	bra.s		fopen2_modesSuite
fopen2_modeB:
	or.w		#$0040,d3
	bra.s		fopen2_modesSuite
	
fopen2_tests_fin:
	tst.w		d4
	beq.s		fopen2_pasappend
	move.l		$180(a5),a0		; SymFind
	jsr		(a0)
	tst.l		d0
	bne.s		fopen2_dejacherche
	bra.s		fopen2_ecraser
fopen2_pasappend:
	btst.l		#1,d3
	beq.s		fopen2_pascreer
	tst.b		d5
	bne.s		fopen2_pascreer
fopen2_ecraser:
	move.l		$170(a5),a0		; SymAdd
	jsr		(a0)
	move.l		d0,(a7)
	beq		fopen2_erreur
	move.l		$1E4(a5),a0		; DerefSym
	jsr		(a0)
	move.l		a0,a2
	move.l		#8,(a7)
	move.l		$240(a5),a0		; HeapAlloc
	jsr		(a0)
	move.w		d0,(a7)
	beq		fopen2_erreur
	move.w		d0,12(a2)
	move.l		$258(a5),a0		; HeapDeref
	jsr		(a0)
	clr.w		(a0)
	btst.l		#6,d3
	bne.s		fopen2_suite
	move.w		#5,(a0)
	move.l		#$00012000,2(a0)
	move.b		#$E0,6(a0)
	bra.s		fopen2_suite
fopen2_pascreer:
	move.l		$180(a5),a0		; SymFind
	jsr		(a0)
fopen2_dejacherche:
	move.l		d0,(a7)
	beq.s		fopen2_erreur
	move.l		$1E4(a5),a0		; DerefSym
	jsr		(a0)
	move.w		12(a0),(a7)
fopen2_suite:
	pea		18
	move.l		$288(a5),a0		; HeapAllocPtr
	jsr		(a0)
	addq.l		#4,a7
	move.l		a0,a3
	beq.s		fopen2_erreur
	move.l		$258(a5),a0		; HeapDeref
	jsr		(a0)
	move.l		a0,a2
	move.l		$268(a5),a0		; HeapLock
	jsr		(a0)
	move.w		d3,10(a3)
	clr.w		12(a3)
	move.l		a2,4(a3)
	move.w		(a7),8(a3)
	clr.w		14(a3)
	move.w		(a2),16(a3)
	addq.w		#2,16(a3)
	tst.b		d4
	beq.s		fopen2_posdebut
	move.w		(a2),d0
	lea		0(a2,d0.w),a2
	move.l		a2,(a3)
	bra.s		fopen2_fin
fopen2_posdebut:
	btst.l		#6,d3
	bne.s		fopen2_binaire
	addq.l		#3,a2                    ; === remplace #3 par #2, et magie ! ===
fopen2_binaire:
	addq.l		#2,a2
	move.l		a2,(a3)
	bra.s		fopen2_fin
fopen2_erreur:
	sub.w		a3,a3
fopen2_fin:
	move.l		a3,a0
	addq.l		#4,a7
	movem.l		(a7)+,d3-d5/a2/a3
	move.l		4(a7),a1
	move.b		fopen2_byte(pc),-1(a1)
	rts
fopen2_byte:
	dc.w		0

>Thibaut:
>Il me semblait avoir observé que les expressions vides présentaient $0002 comme taille sur les 2 premiers octets

Ben non. Vide = 0 (et la taille affichée dans Var-Link sera 2). Avec 2, Var-Link m'affiche 4. Et si je crée un texte vide avec l'éditeur de texte, il y a également 00 05, puis 5 octets de données, avec une taille affichée de 7, donc c'est bien 0 qu'il faut pour un fichier vide.
Et dans fopen.c de TIGCC, je lis également: if(bmode) poke_w(base,0);.

Et le addq.l #3,a2 est bien ce qu'il faut. Voici le code équivalent de TIGCC: fpos=base+(bmode?2:5);. Donc bien une différence de 3.

Bref, soit c'est encore un problème de réorganisation de la RAM, soit ce sont tes fonctions d'écriture qui ne marchent pas.
[edit]Edité par Kevin Kofler le 13-12-2001 à 22:31:47[/edit]

Je confirme : AMS fait +2 à la taille des fichiers, comme si la taille de l'indicateur de taille ne jouait pas sur la taille elle-même.

Sinon, quelques commentaires au sujet de ton code:
1. Après un clr.w (a0), tu peux mettre addq.w #5,(a0), ça prendra moins de place que move.w #5,(a0) (là où je t'avais fait changer les valeurs, j'avais bien proposé addq.w d'ailleurs).
2. Pourquoi HeapDeref, puis HeapLock?

	move.l		$258(a5),a0		; HeapDeref
	jsr		(a0)
	move.l		a0,a2
	move.l		$268(a5),a0		; HeapLock
	jsr		(a0)

Tu peux faire les 2 en même temps avec HLock:

	move.l		$264(a5),a0		; HLock
	jsr		(a0)
	move.l		a0,a2

(Ça serait d'ailleurs plus court que ce que j'avais d'abord proposé, ce qui n'est pas le cas de ta solution.)

Et à ta place, je ne mettrais pas du a5 si tu veux faire une version TIGCC. Ajoute plutôt a6 à ton movem et mets un move.l $c8,a6 au début. (Les fonctions ne devraient pas dépendre de OPTIMIZE_ROM_CALLS.)

Ok merci de tous ces conseils

Mais les bugs restent bien présents, tu as testé avec TIGCC ?

Je vais le faire ce soir (cette nuit en France). Mais je pense que le problème, ce sont les fonctions d'écriture dans le fichier que tu utilises.

Mais j'utilises les fonctions de TIGCClib !!!!!!!

Bon, OK, je vais passer cela au débogueur de VTI.