launcher avec parametres ? - Page 1

Je sais qu'un programme peut en executer un autre à l'aide de la routine EXECUTE_IN_GHOST_SPACE, mais j'ai aussi besoin de comprendre 2 subtilites :

1) peut elle lancer un programme qui demande des parametres ?
2) peut elle permettre des appels de programmes recursif, comme en TI-BASIC ?

Tails :
Je sais qu'un programme peut en executer un autre à l'aide de la routine EXECUTE_IN_GHOST_SPACE, mais j'ai aussi besoin de comprendre 2 subtilites :

1) peut elle lancer un programme qui demande des parametres ? 2) peut elle permettre des appels de programmes recursif, comme en TI-BASIC ?

EXECUTE_IN_GHOST_SPACE n'est pas une routine. Elle fait en sorte qu'une routine pour lancer un autre programme puisse fonctionner, mais tu dois encore écrire cette routine. Et: Oui, tu peux lancer un programme qui demande des paramètres (en utilisant la pile d'expressions), mais un programme qui se lance lui-même est une mauvaise idée, il vaut mieux faire la récursion en interne (à travers une simple fonction récursive).

Enfin, quand je parlais de recursif, c'etait pour savoir si on peut effectuer des appels en cascades : prog_a appelle prog_b, qui lui appelle prog_c, ...

Par contre t'en fais pas pour l'ecriture, je n'en serais pas à ma premiere adaptation (j'ai implementes les .s de la famille de fopen sur ma caltoche, apres avoir ecarte les difficultes de la conversion, tel que le passage des parametres par registres,...,mais malheuresment je peux pas les transferer sur mon ordi)

et je me suis trompé, je voulais parler de la routine enter_ghost_space()

Tails
: Enfin, quand je parlais de recursif, c'etait pour savoir si on peut effectuer des appels en cascades : prog_a appelle prog_b, qui lui appelle prog_c, ...

Oui, on peut.

Ah super! Merci
Par contre, comment tu te sers de la pile d'expression pour passer les parametres?

http://tigcc.ticalc.org/doc/estack.html, http://tigcc.ticalc.org/doc/args.html

Non, non je connais. Si tu mets ces liens, ca veut dire que tu suppose que top_estack pointe,comme d'habitude, sur les parametres.

Admettons maintenant que je veuille lancer un programme qui fait moins de 24k, est ce que je suis quand meme obligé d'appeler enter_ghost_space() ?

Tails
: Non, non je connais. Si tu mets ces liens, ca veut dire que tu suppose que top_estack pointe,comme d'habitude, sur les parametres.

Exact.
Et pour en mettre des tiens, utilise les fonctions push_....

Tails
: Admettons maintenant que je veuille lancer un programme qui fait moins de 24k, est ce que je suis quand meme obligé d'appeler enter_ghost_space() ?

Si tu utilises EXECUTE_IN_GHOST_SPACE, tu ne dois pas appeler enter_ghost_space. Mais tu es quand-même obligé d'utiliser EXECUTE_IN_GHOST_SPACE même si le programme appelé ne dépasse pas la limite de taille.

Donc c'est le enter_ghost_space() qui regardera les parametres, et qui appelera aussi le programme. C'est ca ?

enter_ghost_space est depreceated (d'ailleurs faudrait mettre l'attribut depreceated pour enter_ghost_space).

Tails
: Donc c'est le enter_ghost_space() qui regardera les parametres, et qui appelera aussi le programme. C'est ca ?

Pas du tout. Tu ne dois pas appeler enter_ghost_space si tu utilises EXECUTE_IN_GHOST_SPACE, et ce dernier est ce dont l'utilisation est fortement conseillée C'est écrit:
1. dans la documentation,
2. dans mes messages,
que visiblement tu n'as pas lus...

D'ailleurs faudrait la definir comme ca:
void enter_ghost_space(void) __attribute__((__depreceated__));
dans le header. Non ?

Je partais du principe que, programmant en asm nostub, je ne peux pas définir l'option #EXECUTE_IN_GHOSTSPACE, mais je dois prendre la routine disponible dans les archives de TIGCC. Et je voulais savoir si c'est cette routine qui fait tout.

Non, cette routine est deprecated pour une raison (elle ne marche que dans des cas particuliers).

PpHd :
D'ailleurs faudrait la definir comme ca:
void enter_ghost_space(void) __attribute__((__depreceated__)); dans le header. Non ?

Peut-être.

Mais avec le nouveau linker, on pourrait aussi tout simplement mettre dans enter_ghost_space.s:
.xdef enter_ghost_space, __ref_all_execute_in_ghost_space
enter_ghost_space: rts
pour règler le problème.

Je vais en discuter avec Sebastian.

Et pour en revenir au problème de l'assembleur _nostub, voici la routine EXECUTE_IN_GHOST_SPACE telle qu'elle est dans tipatch.lib, à mettre tout au début du programme:

        lea tigcc_compiled.,%a0
        move.l %a0,%d0
        cmpi.l #0x40000,%d0
        jbcc __ghost_done
        bset.l #18,%d0
        clr.l %d1
        move.w (%a0,-2),%d1
        add.l %d0,%d1
        subq.l #1,%d1
        move.l %d1,-(%sp)
        move.l %d0,-(%sp)
        movea.l 0xC8,%a0
        movea.l (%a0,1384),%a0
        jsr (%a0)
        addq.l #8,%sp
        movea.l 0xC8,%a0
        cmpi.l #1000,(%a0,-4)
        jbcc __ghost_install
        pea __ghost_done(%pc)
        bset.b #2,(%sp,1)
        rts
__ghost_install:
        movem.l %a2-%a6/%d3-%d7,-(%sp)
        lea (%sp,-20),%sp
        move.l #0x3E000,%a3
        move.l %a0,%d0
        andi.l #0x600000,%d0
        addi.l #0x20000,%d0
        move.l %d0,(%sp,12)
        move.l %d0,(%sp,16)
        trap #0xC
        move.w #0x2700,%sr
        move.l #0xF,%d3
        pea __ghost_cont(%pc)
        bset.b #2,(%sp,1)
        clr.w  -(%sp)
        move.l 0xAC,%a0
        jmp (%a0)
__ghost_cont:
        lea (%sp,20),%sp
        movem.l (%sp)+,%a2-%a6/%d3-%d7
__ghost_done:

où tigcc_compiled. est un label marquant le tout début du programme. (C'est un hack affreux qu'on a été obligés d'utiliser avec l'ancien linker. Le nouveau linker gère maintenant un symbole __ld_entry_point prévu pour ça.) Tout le reste ne devrait pas nécessiter d'explication particulière.

Remarque les différences fondamentales avec enter_ghost_space:
1. EXECUTE_IN_GHOST_SPACE s'exécute tout au début. Ça élimine le risque d'avoir une adresse de retour en l'espace non-fantôme qui traîne.
2. EXECUTE_IN_GHOST_SPACE reloge le programme vers l'espace fantôme avec EX_patch. (C'est le ROM_CALL "mystérieux" appelé.) Ça élimine le risque de sauter vers une adresse en l'espace non-fantôme.
Cela fait de EXECUTE_IN_GHOST_SPACE une solution fiable, contrairement à enter_ghost_space.

merci

SI je veux par exemple lancer un executable light(), je fais comment ?

Double-K-> Que fait (ou faisait) enter_ghost_space, exactement?

Si ça ne te suffit pas comme explication, va voir la source (ou la version commentée dans les sources de h220xTSR).

Je viens de lire la source et la doc, donc, à ce que j'ai compris, la protection matérielle HW2 protège la RAM contre l'éxécution mais pas le Ghost Space (cela je le savais déja) mais d'autres protections protègent le Ghost space, et c'est le trap #$B fonction $F qui le déprotège, et seulement s'il est appelé par AMS?
C'est pourquoi on ne peut pas faire tout simplement OR.l #$40000, (A7) et RTS ?

TI se donne vraiment du mal pour nous empêcher d'exécuter de trop gros programmes, même si ce sont des programmes de maths et pas de jeux...

Sinon, y aurait-il un moyen de faire, après ou avant un enter_ghost_space, un EX_patch sur le prog lui-même pour qu'il ajoute automatiquement $40000 à ses sauts?

Link
: Je viens de lire la source et la doc, donc, à ce que j'ai compris, la protection matérielle HW2 protège la RAM contre l'éxécution mais pas le Ghost Space (cela je le savais déja) mais d'autres protections protègent le Ghost space,

C'est la même protection. Seulement, le matériel considère (erronément, mais heureusement) l'espace fantôme comme une partie des derniers 4 KO de RAM. Donc en déprotégeant les derniers 4 KO, on déprotège l'espace fantôme et permet donc l'exécution dans la RAM entière.

et c'est le trap #$B fonction $F qui le déprotège,

Oui. Le but de cette fonction est de déplacer la zone qui est déprotégée, pour la faire correspondre à l'emplacement du programme à exécuter.

et seulement s'il est appelé par AMS?

Exact (mais leur test est carrément mal fait).

C'est pourquoi on ne peut pas faire tout simplement OR.l #$40000, (A7) et RTS ?

Oui.

TI se donne vraiment du mal pour nous empêcher d'exécuter de trop gros programmes, même si ce sont des programmes de maths et pas de jeux...

Ils ont (disent-ils) peur qu'on pirate leurs applications Flash.

Sinon, y aurait-il un moyen de faire, après ou avant un enter_ghost_space, un EX_patch sur le prog lui-même pour qu'il ajoute automatiquement $40000 à ses sauts?

C'est ce que fait EXECUTE_IN_GHOST_SPACE. (Et le fait qu'il est exécuté tout au début, dans le code de démarrage, élimine le problème de l'adresse de retour lors des rts.)