Forum de Ti-Gen.org, le site francophone des TI

Bienvenue Invité ! Se connecter Mes sujets	Administrer
Utilisateurs actifs : Aucun membre + 1 visiteur

Avant de poster sur le forum, il y a des régles de bases à respecter pour une bonne entente et un respect de tous.
Veuillez lire la charte du forum.

:: Index » Forum Ti68K » Programmation Assembleur 68K » sprintf et F-Line (79 réponse(s))

./REPRISE DU POST PRECEDENT (post n°38) Marquer comme non lu.

Kevin Kofler

Ecrit le: Mardi 21 mars 2006 à 15:02

Administrateur

Groupe: Staff de Ti-Gen

Messages: 4814

Membre n°40

Inscrit le 08 février 2004

|======================
| Symbols
|======================
_library
_ti89ti
_ti89
_ti92plus
_v200
_mistub
_readonly
_install_preos
_nosavescreen

1. Ça ne sert à rien de mettre ça avec GNU as, vu que tu peux mettre un .xdef sans un label qui correspond (et c'est ce que TIGCCLIB fait partout pour les symboles de contrôle du linker, donc ça ne risque pas de changer).
2. Il n'y a que les 5 premiers symboles qui ont un sens avec TIGCC. _mistub et _install_preos ne sont pas supportés par ld-tigcc et _readonly et _nosavescreen sont à noter à travers leur numéro de flag (_flag_2 pour _nosavescreen). (C'est aussi pour ça que je dis qu'il ne faut pas utiliser le tios.h de PpHd avec TIGCC.) Ce n'est pas que je n'aime pas ces symboles, mais qu'ils ne fonctionnent pas, donc ça ne sert à rien de les mettre.

Quant à tes RAM_CALLs, il manque le .equ ou .set (GNU as ne distingue pas les deux).
-Edité le Mardi 21 mars 2006 à 15:03 par Kevin Kofler-

Membre de l'équipe de TIGCC: http://tigcc.ticalc.org
Mainteneur du portage Linux/Unix de TIGCC: http://tigcc.ticalc.org/linux/
Membre de l'équipe de CalcForge: http://www.calcforge.org:70/

Participez à la reprise de Ti-Gen!

./Post n°39 Marquer comme non lu.

Folco

Ecrit le: Mardi 21 mars 2006 à 15:13

Administrateur

Groupe: Staff de Ti-Gen

Messages: 1286

Membre n°181

Inscrit le 05 avril 2004

ah ok, les .set sont rajoutés, oubli de ma part.

ok pour _mistub et _install_preos, je les vire.
pour _read_only, quel est le numéro de flag?
et au pire, je peux toujours mettre:

.set _nosavescreen, _flag_2

mais je préfère laisser les symboles, celui qui fera un petit tour dans le header s'y retrouvera plus, perso j'ai jamais retenu les symboles _flag_x, pas assez user-friendly pour moi

et que penses-tu du fait de ne pas réutiliser toutes les antiquités de doorsos.h, qui ne sont là que pour recompiler les progs de 1995?
-Edité le Mardi 21 mars 2006 à 15:14 par Martial Demolins-

<<< Kernel Extremist©®™ >>>
Pas la peine d'aller là plus d'une fois tous les six mois...

"Il faut apprendre pour savoir qu'il faut apprendre pour savoir."

./Post n°40 Marquer comme non lu.

Sasume

Ecrit le: Mardi 21 mars 2006 à 15:41

Membre: Titan

Messages: 918

Membre n°24

Inscrit le 01 février 2004

C'est vraiment dommage que ld-tigcc ne gère pas les bons noms de symboles _nosavescreen et _readonly

./Post n°41 Marquer comme non lu.

Folco

Ecrit le: Mardi 21 mars 2006 à 16:32

Administrateur

Groupe: Staff de Ti-Gen

Messages: 1286

Membre n°181

Inscrit le 05 avril 2004

#crayon#
c'est pour ça que je mettrai les .set correspondant explicitement.

<<< Kernel Extremist©®™ >>>
Pas la peine d'aller là plus d'une fois tous les six mois...

"Il faut apprendre pour savoir qu'il faut apprendre pour savoir."

./Post n°42 Marquer comme non lu.

Sasume

Ecrit le: Mardi 21 mars 2006 à 22:59

Membre: Titan

Messages: 918

Membre n°24

Inscrit le 01 février 2004

Mais je ne crois pas que ça ait un sens

./Post n°43 Marquer comme non lu.

Kevin Kofler

Ecrit le: Mercredi 22 mars 2006 à 05:58

Administrateur

Groupe: Staff de Ti-Gen

Messages: 4814

Membre n°40

Inscrit le 08 février 2004

Normalement, c'est à l'assembleur de faire ça, c'est dommage de hard-coder ces noms dans le linker, ils devraient être déclarés dans le header. La notation _flag_n est beaucoup plus flexible pour l'évolution future (ajout d'un flag, voire changement subtil de la signification d'un flag existant). (Et sinon, je signale aussi que ld-tigcc suit la convention de Julien Muchembled qui a utilisé le flag 2 en premier et réservé les autres.) Cela dit, A68k ne permet pas de faire un equ sur des xdef, et je n'ai pas essayé ce que ça donne avec GNU as.

Quant au numéro du flag de _readonly, cf. la doc de PreOs, je ne le connais pas par coeur.
-Edité le Mercredi 22 mars 2006 à 06:00 par Kevin Kofler-

./Post n°44 Marquer comme non lu.

Folco

Ecrit le: Mercredi 22 mars 2006 à 08:13

Administrateur

Groupe: Staff de Ti-Gen

Messages: 1286

Membre n°181

Inscrit le 05 avril 2004

ok, bon ben je vais tester pour ces histoires de equ sur un xdef, et je chercherai le numéro du flag.

<<< Kernel Extremist©®™ >>>
Pas la peine d'aller là plus d'une fois tous les six mois...

"Il faut apprendre pour savoir qu'il faut apprendre pour savoir."

./Post n°45 Marquer comme non lu.

Folco

Ecrit le: Mercredi 22 mars 2006 à 08:45

Administrateur

Groupe: Staff de Ti-Gen

Messages: 1286

Membre n°181

Inscrit le 05 avril 2004

ok, voilà où j'en suis:
le header: http://databob.free.fr/Volume/files/00000033/kernel.txt
programme de test: http://databob.free.fr/Volume/files/00000033/hello.txt

et le zip comprenant le .s et le .h: http://databob.free.fr/Volume/index.php?f=715DB79F

Sans les optimisations du linker, ça compile (avec --register-prefix-optional). Ceci dit, j'ai un warning bizare en plein milieu du header (end of file not at end of line; new line inserted #confus#

)

Avec les optimisations, je compile un truc de 85 octets, ie. un stub kernel sans rien derrière... #ouin#

Moi pas comprendre encore ce linker magique, qui me dégage mon code... J'arrive pas à lui parler comme il faut...

<<< Kernel Extremist©®™ >>>
Pas la peine d'aller là plus d'une fois tous les six mois...

"Il faut apprendre pour savoir qu'il faut apprendre pour savoir."

./Post n°46 Marquer comme non lu.

FpgForce

Ecrit le: Mercredi 22 mars 2006 à 09:09

Membre: Maître Ultime

Messages: 1295

Membre n°216

Inscrit le 29 avril 2004

Ceci dit, j'ai un warning bizare en plein milieu du header (end of file not at end of line; new line inserted #confus#

)

Et si tu laisse une ligne vide à la fin de ton code source, le warning disparait pas par hasard ?
-Edité le Mercredi 22 mars 2006 à 09:09 par FpgForce-

./Post n°47 Marquer comme non lu.

Folco

Ecrit le: Mercredi 22 mars 2006 à 09:18

Administrateur

Groupe: Staff de Ti-Gen

Messages: 1286

Membre n°181

Inscrit le 05 avril 2004

ah si

c'est donc réglé, merci bien.
donc toujours plus que ce problème de compilation...

naturellement, c'est le "remove unused sections" qui provoque ça.
ça voudrait dire que mon symbole _main n'est pas exporté?

edit-> et pas moyen de savoir si le .set no_savescreen, _flag_2 marche... :'(

edit2-> je passe à GNU as parceque c'est GNU, moins buggué et plus optimisé, mais la simplicité et quelques features de A68k me manqueront toujours :'(

-Edité le Mercredi 22 mars 2006 à 14:48 par Martial Demolins-

<<< Kernel Extremist©®™ >>>
Pas la peine d'aller là plus d'une fois tous les six mois...

"Il faut apprendre pour savoir qu'il faut apprendre pour savoir."

./Post n°48 Marquer comme non lu.

Kevin Kofler

Ecrit le: Mercredi 22 mars 2006 à 16:07

Administrateur

Groupe: Staff de Ti-Gen

Messages: 4814

Membre n°40

Inscrit le 08 février 2004

Pour voir si le set marche, essaie d'écrire un truc sur l'écran et regarde si ça reste.

Pour la section qui est virée, tu mets bien ton .xdef _main?

./Post n°49 Marquer comme non lu.

Folco

Ecrit le: Mercredi 22 mars 2006 à 16:16

Administrateur

Groupe: Staff de Ti-Gen

Messages: 1286

Membre n°181

Inscrit le 05 avril 2004

Kevin-> j'ai pas d'ému sous la main. Par contre, j'ai mis les liens vers le header et le source du test, ça doit pas être dur à vérifier.

pour la section virée, voici le code (qui fait 220 bytes, stub compris, dans un seul source):

  .include  "kernel.h"

  .extern    _main
  .extern    _ti89

_main:  pea.l  LCD_SIZE
  jsr  ams__HeapAllocPtr
  movea.l  a0,a2
  beq.s  quit
  lea.l  LCD_MEM,a3
  move.w  #LCD_SIZE,d0  |LCD_SIZE
  lsl.w  #2,d0    |/4
  subq.w  #1,d0    |-1
  move.w  d0,d3
loop:  move.l  (a3),(a2)+
  clr.l  (a3)+
  dbra.w  d0,loop
  move.w  #1,(sp)
  pea.l  str(pc)
  clr.l  -(sp)
  jsr  ams__DrawStr
  jsr  ams__ngetchx
loop2:  move.l  -(a2),-(a3)
  dbra.w  d3,loop2
  move.l  a2,(sp)
  jsr  ams__HeapFreePtr
  addq.l  #8,sp
quit:  addq.l  #4,sp
  rts
str:  .asciz  "Hello world!"
  .end

moi pas comprendre...

-Edité le Mercredi 22 mars 2006 à 16:17 par Martial Demolins-

<<< Kernel Extremist©®™ >>>
Pas la peine d'aller là plus d'une fois tous les six mois...

"Il faut apprendre pour savoir qu'il faut apprendre pour savoir."

./Post n°50 Marquer comme non lu.

Sasume

Ecrit le: Mercredi 22 mars 2006 à 17:52

Membre: Titan

Messages: 918

Membre n°24

Inscrit le 01 février 2004

Kevin Kofler :
Normalement, c'est à l'assembleur de faire ça, c'est dommage de hard-coder ces noms dans le linker, ils devraient être déclarés dans le header.

Je ne comprends pas #confus#

Il faudrait faire comment concrètement ?
-Edité le Mercredi 22 mars 2006 à 17:52 par Sasume-

./Post n°51 Marquer comme non lu.

Folco

Ecrit le: Jeudi 23 mars 2006 à 08:29

Administrateur

Groupe: Staff de Ti-Gen

Messages: 1286

Membre n°181

Inscrit le 05 avril 2004

Bon, ben sans réponse de Kevin, je vais avoir du mal

d'autant plus que si ma section qui contient _main est coupé, c'est que le point d'entrée n'est pas reconnu, donc j'ai rien à passer dans la moulinette du débuggueur pour vérifier ci ou ça :S

<<< Kernel Extremist©®™ >>>
Pas la peine d'aller là plus d'une fois tous les six mois...

"Il faut apprendre pour savoir qu'il faut apprendre pour savoir."

./Post n°52 Marquer comme non lu.

Folco

Ecrit le: Jeudi 23 mars 2006 à 13:03

Administrateur

Groupe: Staff de Ti-Gen

Messages: 1286

Membre n°181

Inscrit le 05 avril 2004

bon, je vais compiler un programme en C (kernel) et examiner le .s correspondant.

<<< Kernel Extremist©®™ >>>
Pas la peine d'aller là plus d'une fois tous les six mois...

"Il faut apprendre pour savoir qu'il faut apprendre pour savoir."

./Post n°53 Marquer comme non lu.

Folco

Ecrit le: Jeudi 23 mars 2006 à 13:21

Administrateur

Groupe: Staff de Ti-Gen

Messages: 1286

Membre n°181

Inscrit le 05 avril 2004

alors voilà le source C, compilé sans la moindre optimisation du linker, au format doorsos ou compatible (ça plante avec une table de relogement compressée...):

#include <tigcclib.h>

// Main Function
void _main(void)
{
ngetchx();
}

et voici le .s produit:

  .file  "c.c"
#NO_APP
  .text
tigcc_compiled.:
  .text
#APP
  .xdef _ti89
  .text
  .xdef _ti89ti
  .text
  .xdef _ti92plus
  .text
  .xdef _v200
  .text
  .xdef __ref_all___startup_code
  .text
  .set _A_LINE,0xA000
  .text
  .xdef __ref_all___kernel_format_data_var
  .text
  .xdef __ref_all___kernel
  .text
  .xdef __ref_all___preos_headers
  .text
  .set MT_TEXT,0x8000
  .text
  .set MT_XREF,0x9000
  .text
  .set MT_ICON,0xA000
  .text
  .set MT_CASCADE,0x4000
#NO_APP
  .section  .text.__main,"x"
  .even
  .globl  __main
__main:
#APP
  .xdef __ref_all___set_file_in_use_bit
#NO_APP
  jsr _ROM_CALL_51:l
  rts

rien n'y a fait, j'ai rajouté les .globl, .section ou autre, j'ai pas réusis à compiler ce que je voulais. toujours ma section principale rejetée par tigcc :/

<<< Kernel Extremist©®™ >>>
Pas la peine d'aller là plus d'une fois tous les six mois...

"Il faut apprendre pour savoir qu'il faut apprendre pour savoir."

./Post n°54 Marquer comme non lu.

Folco

Ecrit le: Jeudi 23 mars 2006 à 13:26

Administrateur

Groupe: Staff de Ti-Gen

Messages: 1286

Membre n°181

Inscrit le 05 avril 2004

en mixant tout le barratin produit par le préprocesseur de tigcc avec mon code, j'arrive toujours au même résultat #ouin#

Kevin-> on peut vraiment compiler en kernel avec GNU as??? #confus#

edit-> je me souviens maintenant, à la suite de mon début de GFA editor, j'avais voulu porter le source de mouselib pour GNU as, mais ça avait avorté parceque ça voulait pas compiler avec le "remove unused sections", malgré les exports corrects de mouselib__000x...

je me plante peut-être, mais la TIGCC Team va peut-être devoir se pencher un minimum sur son linker

j'iamerais pas faire un second come back vers A68k pour faute de compilation de TIGCC

-Edité le Jeudi 23 mars 2006 à 15:59 par Martial Demolins-

<<< Kernel Extremist©®™ >>>
Pas la peine d'aller là plus d'une fois tous les six mois...

"Il faut apprendre pour savoir qu'il faut apprendre pour savoir."

./Post n°55 Marquer comme non lu.

Kevin Kofler

Ecrit le: Jeudi 23 mars 2006 à 16:22

Administrateur

Groupe: Staff de Ti-Gen

Messages: 4814

Membre n°40

Inscrit le 08 février 2004

1. C'est .xdef ou .globl qu'il faut mettre, pas .extern.
2. Si tu n'utilises pas le code de démarrage de TIGCCLIB, ta fonction principale doit s'appeler _main, pas __main. En gros, c'est soit ça:

.xdef _ti89
.xdef _main
_main:

soit ça:

.xdef _ti89
.xdef __ref_all___startup_code
.xdef __ref_all___kernel
.xdef __main
__main:

(Faut pas mélanger.)
Et sinon je te signale qu'il ne faut pas cocher/définir l'option "PreOs compressed headers" parce qu'elle ne fonctionne pas, PpHd a viré ça dans PreOs 0.70 au lieu de finaliser l'implémentation qui était dans les versions de développement. (Tous les flames pour cette décision sont à envoyer à PpHd, pas moi, je n'y peux rien.)
3. Le problème des exports des libs qui n'empêchaient pas la suppression de la section a été corrigé (et c'était bien un problème de linker, pas d'assembleur, donc utiliser A68k n'y change rien).
4. Je ne peux pas traîner sur le forum 24/7, j'ai d'autres choses à faire aussi!

Sasume :

Kevin Kofler :
Normalement, c'est à l'assembleur de faire ça, c'est dommage de hard-coder ces noms dans le linker, ils devraient être déclarés dans le header.

Je ne comprends pas #confus#

Il faudrait faire comment concrètement ?

.equ _nosavescreen,_flag_2, idéalement.
Mais je ne sais pas si ça marche avec le .xdef.

./Post n°56 Marquer comme non lu.

Sasume

Ecrit le: Jeudi 23 mars 2006 à 16:45

Membre: Titan

Messages: 918

Membre n°24

Inscrit le 01 février 2004

J'en doute

./Post n°57 Marquer comme non lu.

Folco

Ecrit le: Jeudi 23 mars 2006 à 16:49

Administrateur

Groupe: Staff de Ti-Gen

Messages: 1286

Membre n°181

Inscrit le 05 avril 2004

1-> je me suis rendu compte de ma faute en compulsant le doc, et je l'ai corrigée.

2-> ok pour la syntaxe à adopter, merci bien! et ok pour les explications des tables de relogements compressés, je pensais que ça venait du fait qu'il n'y avait qu'un seul relogement (ngetchx) dans mon "code".

3-> ah ok. Tant mieux. C'était pas à Flanker que c'était arrivé ce problème?

4-> Je sais!!!

merci pour ta réponse et ton support de toute façon, c'est sympa à toi de le faire, ce n'est en aucun cas une obligation.

.equ _nosavescreen,_flag_2

j'ai mis:

.set _nosavescreen,_flag_2

normalement c'est pareil, il n'y a pas d'erreur à la compilation, mais je n'ai pas pu tester encore (toujours pas d'ému...).

Merci encore pour tout!

<<< Kernel Extremist©®™ >>>
Pas la peine d'aller là plus d'une fois tous les six mois...

"Il faut apprendre pour savoir qu'il faut apprendre pour savoir."