Joyeux Noël Kevin ! - Page 1

Donc, comme convenu, j'offre au projet TIGCC file.azr sans délai
Tout a été testé sauf rename et remove, qui devraient marcher, mais sait-on jamais...

::               FILE
                ======
 
 Ce fichier doit etre visualise avec
 l'IDE inclus dans le SDK Azur.
 L'editeur integre de la TI le rend
 illisible.
 
 Le langage Azur, le compilateur Azur,
 l'ensemble des fichiers (tels que
 celui-ci) constituant la bibliotheque
 Azur, le code des fonctions de cette
 bibliotheque, sont proteges par les
 droits de la propriete intellectuelle.
 
 Pour reprendre tout ou partie de la
 bibliotheque dans un programme ecrit
 en un langage autre que l'Azur,
 contactez l'auteur.
 
 (c) 2001 Thibaut Barthelemy
 
 Pour toute question, remarque, idee
 d'optimisation, remerciement, ou pour
 proposer une nouvelle fonction...
 -> barthib@hotmail.com
 
 Derniere correction :
 -> le 22 decembre 2001 a 11h23
::


#redecoff
#commoff


: Fonctions de cette librairie
[
 extern void
  @fopen  [byte @Nom,@Mode],
  @freopen[byte @Nom,@Mode;void @Fich];
 extern word
   fclose [void @Fich],
   rename [byte @CurrentName,@NewName],
   remove [byte @FileName];
 
 extern void
  @GetDataPtr[void @Fich];
]

: To do :
:  fgetc fputc fgets fputs fread fwrite
:  fprintf fseek feof rewind ungetc

:         +----------------+
:         | Implementation |
:         +----------------+


<
fopen:
; Merci a Kevin Kofler pour
; le debogage de ce code
 move.l  4(a7),a0
 move.l  8(a7),a1
 movem.l d3-d5/a2,-(a7)
 
 move.b  -(a0),file_byte
 clr.b   (a0)+
fopen_loop:
 tst.b   (a0)+
 bne.s   fopen_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:
 or.w    #$0002,d3
 bra.s   fopen_modesSuite
fopen_modeR:
 or.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(a5),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(a5),a0   ; SymAdd
 jsr     (a0)
 move.l  d0,(a7)
 beq.s   fopen_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.s   fopen_erreur
 move.w  d0,12(a2)
 move.l  $258(a5),a0   ; HeapDeref
 jsr     (a0)
 clr.w   (a0)
 btst.l  #6,d3
 bne.s   fopen_suite
 move.l  #$00050001,(a0)
 move.l  #$2000E000,4(a0)
 bra.s   fopen_suite
fopen_erreur:
 sub.w   a2,a2
 bra.s   fopen_fin
fopen_pascreer:
 move.l  $180(a5),a0   ; SymFind
 jsr     (a0)
fopen_dejacherche:
 move.l  d0,(a7)
 beq.s   fopen_erreur
 move.l  $1E4(a5),a0   ; DerefSym
 jsr     (a0)
 move.w  12(a0),(a7)
fopen_suite:
 pea     (18).w
 move.l  $288(a5),a0   ; HeapAllocPtr
 jsr     (a0)
 addq.l  #4,a7
 move.l  a0,a2
 beq.s   fopen_erreur
 move.l  $264(a5),a0   ; HLock
 jsr     (a0)
 clr.w   12(a2)
 move.l  a0,4(a2)
 move.w  (a7),8(a2)
 clr.w   14(a2)
 move.w  (a0),16(a2)
 addq.w  #2,16(a2)
 tst.b   d4
 beq.s   fopen_posdebut
 moveq   #0,d0
 move.w  (a0),d0
 add.l   d0,a0
 bra.s   fopen_EOF
fopen_posdebut:
 btst.l  #6,d3
 bne.s   fopen_binaire
 addq.l  #3,a0
fopen_binaire:
 addq.l  #2,a0
fopen_EOF:
 move.w  d3,10(a2)
 move.w  a0,d1
 move.l  a0,(a2)
 sub.w   6(a2),d1
 sub.w   16(a2),d1
 btst.l  #6,d3
 seq     d0
 and.w   #2,d0
 add.w   d0,d1
 bne.s   fopen_fin
 or.w    #$0020,10(a2)
fopen_fin:
 move.l  a2,a0
 addq.l  #4,a7
 movem.l (a7)+,d3-d5/a2
 move.l  4(a7),a1
 move.b  file_byte(pc),-(a1)
 rts


freopen:
 move.l  12(a7),-(a7)
 bsr.s   fclose
 addq.l  #4,a7
 bra     fopen


fclose:
 move.w  d3,-(a7)
 move.w  #-1,d3
 move.l  6(a7),a0
 beq.s   fclose_fin
 btst.b  #4,10(a0)
 sne     d3
 ext.w   d3
 move.l  4(a0),a1
 move.w  (a1),-(a7)
 addq.w  #2,(a7)
 clr.w   -(a7)
 move.w  8(a0),-(a7)
 move.l  $27C(a6),a0   ; HeapUnlock
 jsr     (a0)
 move.l  $274(a6),a0   ; HeapRealloc
 jsr     (a0)
 move.l  12(a7),(a7)
 move.l  $28C(a6),a0   ; HeapFreePtr
 jsr     (a0)
 addq.l  #6,a7
fclose_fin:
 move.w  d3,d0
 move.w  (a7)+,d3
 rts


rename:
 lea     -64(a7),a7
 move.l  72(a7),a0
 lea     (a7),a1
 clr.b   (a1)+
rename_loop1:
 move.b  (a0)+,(a1)+
 bne.s   rename_loop1
 pea     -1(a1)
 move.l  $180(a6),a0    ; SymFind
 jsr     (a0)
 tst.l   d0
 bne.s   rename_err
 move.l  72(a7),a0
 lea     32(a7),a1
 clr.b   (a1)+
rename_loop2:
 move.b  (a0)+,(a1)+
 bne.s   rename_loop2
 pea     -1(a1)
 move.l  $18C(a6),a0    ; SymMove
 jsr     (a0)
 lea     72(a7),a7
 tst.w   d0
 seq     d0
 ext.w   d0
 rts
rename_err:
 lea     68(a7),a7
 moveq   #-1,d0
 rts


remove:
 move.l  4(a7),a0
 move.b  -(a0),file_byte
 clr.b   (a0)+
remove_loop:
 tst.b   (a0)+
 bne.s   remove_loop
 pea     -1(a0)
 move.l  $178(a6),a0    ; SymDel
 jsr     (a0)
 addq.l  #4,a7
 tst.w   d0
 seq     d0
 ext.w   d0
 move.l  4(a7),a1
 move.b  file_byte(pc),-(a1)
 rts


GetDataPtr:
 move.l  4(a7),a0
 beq.s   GetDataPtr_err
 move.l  (a0),a0
GetDataPtr_err:
 rts


file_byte:
 dc.w    0
>


:            +---------+
:            | The end |
:            +---------+

[edit]Edité par Thibaut le 24-12-2001 à 18:24:00[/edit]

Mon fameux fopen prend 144 octets de moins que celui de TIGCC.

Au nom d'au moins un programmeur C, merci
joyeux Noël à toi Kevin, ainsi qu'à toi Thibaut, ainsi qu'à ceux qui utiliseront cette fonction;

arf des fonctions y'en a 5 là

dans le post précédent, tu parlais uniquement de la fonction fopen, en disant qu'elle était optimisée => je parlais de cette fonction aussi !
les autres, je ne sais pas si elles sont ou non différentes de celles de TIGCC => je ne dis rien

Les autres fonctionnent comme celles de TIGCClib, des bugs en moins (et probablement de la taille aussi) !

OK.
dans ce cas, "... à ceux qui utiliseront CES fonctionS"

(cf l'idée par mini-msg pr le comparatif...)

L'union fait la force

Merci beaucoup, Azur va pouvoir avancer plus vite grâce à toi. Si t'es sage tu auras les sources du compilo pour éventuellement aider aussi de ce côté

c pas gagné pr que je puisse aider sur le compilo, je ne connait rien à ce type de programme
et de rien : ça me servira aussi puisuqe ça me permettra de coder en autre chose que l'ASM sur ma TI =>W bien pratique qd on a pas de PC la semaine pr tester les algos, par ex

Merci pour ces routines. Il faudra juste que je discute avec Sebastian et Zeljko avant de mettre ça dans la sortie officielle de TIGCCLIB. Je ferai probablement d'abord une conversion non-officielle de tes sources pour TIGCC, puis je les testerai, puis je discuterai avec le reste de l'équipe pour l'intégration officielle. (Je ne pense pas qu'ils diront non - je ne vois pas pourquoi ils le feraient.)

Juste une chose: S'il te plaît change-nous l'entête pour refléter le fait que tu le contribues à nous. Remplace ça:

 Pour reprendre tout ou partie de la
 bibliotheque dans un programme ecrit
 en un langage autre que l'Azur,
 contactez l'auteur.

Par:

 J'ai contribué ce fichier au projet TIGCC
 en espérant qu'il leur sera utile pour
 TIGCCLIB. Je permets à l'équipe de
 TIGCC de l'adapter à TIGCC et de le
 placer sous la même licence que le
 reste de TIGCCLIB.

 Ceci n'est valable que pour ce fichier
 précis. Le reste de la bibliothèque
 Azur reste exclusif à l'Azur jusqu'à
 décision contraire.

[edit]Edité par Kevin Kofler le 24-12-2001 à 19:13:04[/edit]

Voici les avantages de :
* fclose : 999 octets par fichier (pire des cas) ne sont plus gaspillés
* rename : si le fichier NewName existe déjà, la fonction renvoie EOF, mais ne supprime pas le fichier (contrairement à TIGCC )

* d'une manière générale : fonctions plus petites

Et pour l'entête?

Pour le changement d'en tête : pas avant que TIGCC ai tout repris. Le "copyright T.B." sera remplacé par "programmé par T.B"
J'écrirai à la place de "Pour reprendre tout ou partie de la bibliotheque dans un programme ecrit en un langage autre que l'Azur, contactez l'auteur.", "Vous pouvez retrouver ces fonctions dans la bibliothèque de TIGCC, adaptées de l'Azur par Kevin Kofler".

Je suppose que vous ferez de même en face de la doc des fonctions de l'aide de TIGCC "Fonction provenant de la bibliothèque du compilateur Azur" avec un lien si possible vers mon site.

>pas avant que TIGCC ai tout repris.

C'est-à-dire soit on reprend tout, soit on ne reprend rien? Pas très tolérant comme licence... Je dirais même: ce n'est pas vraiment compatible avec les termes de TIGCCLIB. Pas que je n'aie pas l'intention de tout reprendre si c'est vraiment mieux (sauf peut-être pour rename - je vais devoir regarder ce que demande le standard ANSI), mais il faut surtout qu'on ait le droit de remplacer une partie de tes routines par des routines encore meilleures si quelqu'un arrive à en contribuer d'encore meilleures à un moment.

Et nous, on met quoi dans l'entête? Est-ce que le texte ci-dessous te va?

/* These routines were originally part of the Azur runtime library by Thibaut Barthélemy. See [URL du projet Azur] for more information about his Azur C-like language and on-calc compiler project. They were contributed to TIGCCLIB by their author (Thibaut Barthélémy) and adapted to work with TIGCC by Kevin Kofler [and ... s'il y a d'autres qui m'aident]. The author has given us explicit permission to modify and adapt these routines and to distribute them under the same terms as the rest of TIGCCLIB. We are looking forward to achieve the same degree of cooperation for the rest of the Azur runtime at some time. */
[edit]Edité par Kevin Kofler le 24-12-2001 à 20:21:55[/edit]

Tout me convient, mais la dernière phrase je ne la comprend pas : "We are looking forward to achieve the same degree of cooperation for the rest of the Azur runtime at some time".

Moi je parlerai de vous dans la doc. Et vous ?

>> il faut surtout qu'on ait le droit de remplacer une partie de tes routines par des routines encore meilleures
Bien évidemment, je n'ai aucune raison de refuser !

>> C'est-à-dire soit on reprend tout, soit on ne reprend rien? Pas très tolérant comme licence...
Mais si, pour le moment vous reprenez file, dans un moment tout !
[edit]Edité par Thibaut le 24-12-2001 à 21:07:48[/edit]

squale92 : réponse à ta question en mini-message :
il faut remplacer tous les a6 par a5, et activer OPTIMIZE_ROM_CALL. Ou garder l'adressage par a6, mais alors tu va devoir modifier un peu chaque fonction en sauvant a6 au début (+ restauration à la fin of course), et ajouter move.l $C8,a6 juste après cette sauvegarde.

N'oublie pas également de déclarer ces fonctions, c'est à dire de te faire un *.h où tu écris des choses du genre extern short rename(char *CurrentName, char*NewName);

Enfin, assemble les fonctions avec A68k dans un *.o séparé (vraiment pas dur avec TIGCC, je suppose que tu sais cliquer sur "Add assembly file" du fichier *.asm : SECTION ".data" xdef rename2), en n'oubliant pas en en-tête

>Thibaut:
>>> C'est-à-dire soit on reprend tout, soit on ne reprend rien? Pas très tolérant comme licence...
>Mais si, pour le moment vous reprenez file, dans un moment tout !

Nous (du moins moi, mais je pense que c'est pareil pour Sebastian et Zeljko), on compte reprendre ce qui nous sert à nous. Pas forcément tout.
Et comme j'ai dit, il faut que si quelqu'un nous sort une ou deux routines de fichiers encore plus performantes, nous puissions remplacer les tiennes (et seulement ces 1 ou 2 routines) par celles-là.
Mais là:
>>> il faut surtout qu'on ait le droit de remplacer une partie de tes routines par des routines encore meilleures
>Bien évidemment, je n'ai aucune raison de refuser !
ça a l'air de bien éclaircir le tout.

Et si tu veux, je ne mettrai pas la dernière phrase (même si je ne vois pas ce qui te gène là-dedans vu le promesses que tu m'as faites).

>Moi je parlerai de vous dans la doc. Et vous ?

Ton nom apparaîtra certainement dans l'historique (dans la documentation) ainsi que dans les sources, et je pense qu'il sera aussi dans la documentation des routines concernées elles-mêmes.

Et je vous rappelle à tous que Sebastian et Zeljko n'ont pas encore dit oui (j'ai voulu éclaircir les conditions d'usage le plus possible avec toi avant de leur demander), et qu'il faudra certainement attendre un peu (mais probablement moins de 1,5 mois - tu sais pourquoi je dis ça, Thibaut ) avant de voir une release de TIGCC les comportant.
[edit]Edité par Kevin Kofler le 24-12-2001 à 22:18:18[/edit]

>> il faut que si quelqu'un nous sort une ou deux routines de fichiers encore plus performantes, nous puissions remplacer les tiennes (et seulement ces 1 ou 2 routines) par celles-là
Mais je n'ai aucune raison ni aucun droit de le refuser ! Ca me surprend que tu t'inquiètes pour ça !

>> on compte reprendre ce qui nous sert à nous
Pareil, je ne vous oblige à rien ! Vous reprenez ce que vous voulez. Ca aussi ça me surprend...

>> je ne mettrai pas la dernière phrase (même si je ne vois pas ce qui te gène là-dedans[...])
Je n'ai pas dit que ce qui y est dit me gênait, je n'ai même pas réussi à traduire !


Conclusion : il ne faut pas boire autant le soir de Noël

C'est bien les routines de file handling plus efficaces et débuggées. Parce que les octets gaspillés c'était pas super...

Oui, mais je vous avertis que Sebastian et moi, on est très occupés à cause de tout un paquet de problèmes de linking avec les projets A68k et qu'on n'aura pas forcément le temps de nous occuper de ça tout de suite.

Pourquoi a68k ne marche-t-il plus ??

Kevin : tant mieux ça me laisse le temps de débuguer

Effectivement, j'ai trouvé une erreur de syntaxe non-détectée par A68k. Dans fopen_modeP : btst.b #0,d3... Heureusement ce n'est qu'un détail !

>XDanger: Pourquoi a68k ne marche-t-il plus ??

Tout est règlé dans la dernière version de TIGCC.