1

J'avais posté ça à l'époque : blogs/blog.php?id=400&i=19#com

Mais sans tester. Le jmp truc__0000, ça va faire qu'au relogement du loader, le programme ou la lib truc va être relogé, non ? Donc ça sera relogé sous AMS et PedroM de toute façon ? Comment faire ce que je veux ?

2

2 programmes (lié dans une pack archive).
Le premier qui est relogé mais tout petit. Qui va récupérer toutes les adresses et les tables qu'il va donné
au second programme, taggué read only, sans relogement, qui sera en flash.

Ce que tu me montres est le premier programme.

3

C'est exactement ça que je fais quand je code pour PedroM uniquement, et ça marche très bien. Mais ça passera pas sous AMS à cause du tag read-only. Comment faire alors ? Le tag va tout faire foirer, vu que PreOS le respecte également sous AMS (à ma connaissance).
Un truc crade, mais qui devrait marcher, serait de ne pas mettre le tag, puis :

- Sous AMS : kernel::LibsExec ou kernel::exec sous AMS (ça sera relogé en RAM, même si la grosse partie ne contient en fait pas de relogement)

- Sous PedroM : kernel::LibsBegin, puis kernel::LibsPtr(partie principale, fonction 0000), puis un LibsEnd, et enfin un jsr ptr0000. Le pack archive ne bougera pas en archive, ne bougera pas en RAM non plus vu que le loader sera relogé et en cours d'exécution, mais c'est crade quand même, non ?

En tout cas, ça devrait marcher comme ça ?

4

Non. Mieux vaut faire deux binaires différents.

5

Ca pourrait casser ? Et c'est lourd de faire deux binaires différents (pour les end-users (si je finis mon prog (si je release grin)))

6

L'end user de pedrom sera assez intelligent pour utiliser son programme dédié smile

7

Oui, je suis d'accord. Mais entre deux cours, pas pouvoir passer un soft à un copain parce que l'un est sous PedroM et l'autre sous AMS c'est con (oué ok remarque, ça risque pas d'arriver grin)

Sinon, ma méthode aurait marché ?

8

Non, car kernel::LibsExec ne relogera pas en ram.

9

Ah bon ? LibsExec ne reloge pas en RAM ? Ca foire alors s'il y a des relogements à résoudre ? Ou ça ne reloge en RAM que s'il y a des relogements ?
35-kernel::LibsExec(char *lib_name, WORD function, BYTE version, ...) (Preos only)

The parameters are pushed on the stack.
It calls the function without modifying the registers, and it pops its argument
during the call (LIB_DESCRIPTOR, function, and version).
BYTE doesn't follow the C convesion for char (Sorry). Uses macro instead.

It relocs the library, calls the function and unreallocs the library.
The parameters pushed on the stack are corrupted. If there is an error, the parameter 'lib_name' equals zero after the call.

Je cherche à comprendre, si ce n'est pas un des deux raisons que j'ai donné... confus

10

A cause du flags read only qui assure aucun relogement.

11

Ok, donc ça va planter lamentablement si jamais fallait en faire quand même.
La solution est donc de créer un handle en RAM sous AMS, d'y copier le code et de l'exécuter. #tripropre#

12

#trideuxprogrammesseraitplussimpleetprendraitmoinsdeplace#

13

C'est sûr grin

14

Ce que tu peux faire, c'est coder ton programme comme un programme _nostub, puis rajouter un fake stub qui ne fait que lancer le programme sans passer par le kernel: PedroM reconnaîtra le programme comme un programme kernel et le lancera directement en archive, respectant le flag readonly, AMS lancera le programme comme un programme _nostub avec la recopie en RAM automatique.
avatar
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é

15

Sauf via un lanceur de programme externe. Mauvais idée.

16

Bah, le TICT Explorer va aussi lancer ça de la manière conventionnelle. smile
avatar
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é

17

Oui, mais j'ai l'impression que ce n'est pas ce que PpHd veut wink

Si je comprends bien ce que tu as écrit dans ./14, PedroM regarde un peu mieux l'intérieur des programmes kernel-based que ne le font, par exemple, ttstart (pas du tout) et TICT-Explorer 1.40 Beta (juste pour la détection et l'affichage du fait que c'est un programme kernel-based). PedroM est donc capable de lancer des programmes kernel-based sans recopie en RAM (s'il y a le flag qui va bien), même si leur stub n'appelle pas kernel::Exec (0x34.l, il me semble), et cette capacité est perdue si on utilise ttstart et TICT-Explorer 1.40 Beta (qui recopient inconditionnellement en RAM).
J'ai bien compris ?
avatar
Membre de la TI-Chess Team.
Co-mainteneur de GCC4TI (documentation en ligne de GCC4TI), TIEmu et TILP.
Co-admin de TI-Planet.

18

oui

19

PpHd (./12) :
#trideuxprogrammesseraitplussimpleetprendraitmoinsdeplace#

Je pense avoir trouvé la solution : kernel::LibsExec sous PedroM, et kernel::ExtractFromPack//kernel::exec sous AMS.