J'ai eu une idée... - Page 1

Tu viens de réinventer les overlays grosso modo

Mais tu t'embètes pour rien. Ecris du code pic, et tu peux l'exécuter directement en flash, c'est quand même plus simple. D'ailleurs à ce sujet, si tu passes par là PpHd, tu pourrais décrire comment tu gères l'attribut correspondant ? Me souviens plus du nom, mais je pense que tu verras celui dont je parle.

overlays? moi pas compris

C'est une technique qui date de msdos de recouvrement de code pour exécuter un programme plus gros que les 64ko maximums (adressage par offset 16 bits), et même plus gros que la mémoire disponible.

écrire du pic ou éxécuter en RAM ne résoud pas le problème des relogements,

bah....du pic est forcément sans relogements, donc si ça résoud le problème

Pour l'edit, ça dépend : si PreOS est capable de lancer directement un programme en mémoire archive ou pas. S'il ne l'est pas, il te faut effectivement un loader (ou alors harceler pphd pour qu'il l'ajoute ).

Ben si tu veux utiliser des dll avec du code PIC faut gérer toi-même leur chargement, comme avec dlopen() sous gnu, ou LoadLibrary sous win32.
Pour les ram call, j'en ai pas la moindre idée, mais c'est une bonne question, ça pourrait poser problème ^^

Je vois mal comment le kernel pourrait faire ce travail sans trop de rigidité dans la procédure de démarrage... (allocation d'un handle (un seul??), passage de l'adresse ou du handle par registre (ou par la pile??), ce sont les premières contraintes qui me viennent comme ça

que veux-tu dire ?
Je vois pas où est la différence fondamentale par rapport à ce qui se fait actuellement ? Il suffit de ne pas copier le programme en ram et de ne pas effectuer les relogements, à part ça c'est un programme normal...

Est-ce que tu as réfléchi à comment gérer les appels en cascade, pour le retour notamment ? [edit] en fait c'est pas tellement compliqué, il suffit de s'assurer de recharger à chaque fois le module appelant en mémoire.

spectras
: Mais tu t'embètes pour rien. Ecris du code pic, et tu peux l'exécuter directement en flash, c'est quand même plus simple.

PreOS ne permet pas l'exécution en Flash, parce que sous AMS c'est moyennement possible ( http://membres.lycos.fr/extended/FlashROM_exec_protection.txt ).

Martial Demolins :
Et les RAM calls, ils marchent comment? Ils sont résolus en temps d'éxécution ou quand PreOS reloge le programme?

Au relogement, comment voudrais-tu faire autrement ?

En fait je vois pas trop ce que le kernel pourrais apporter, sachant qu'en plus toutes les fonctions sont dans la même lib.
Tu pourrais voir ça de façon beaucoup plus simple :

	; push params...
	trap 	#cequetuveux
	bsr.w	func

	; ...

	dc.w	endfunc-func ; taille du "module"
func:
	; ...
endfunc	

Avec un gestionnaire qui s'inscrit en hook de trap, qui retrouve l'adresse de "func" dans le fichier en archive en lisant l'offset du bsr du module appelant, et après exécution qui revient juste après le bsr.
Après si tu veux que le programme soit en C ça rend les choses un peu plus complexes.

Extended> on peut surement modifier ams pour dégager la protection.

pas besoin de modifier ams pour ça, je crois

spectras :
Extended> on peut surement modifier ams pour dégager la protection.

Oui, bien sûr (Xpand le fait).

Flanker :
pas besoin de modifier ams pour ça, je crois

Mmm ?

ExtendeD
:

spectras :
Extended> on peut surement modifier ams pour dégager la protection.

Oui, bien sûr (Xpand le fait).

Flanker :
pas besoin de modifier ams pour ça, je crois

Mmm ?

la protection de l'exécution est au niveau des ports $700000, non ?

Oui, mais ports protégés par la "Protection" comme il dit Eilert, heureusement (ou malheureusement, selon le point de vue)

Et ça apporte quoi par rappport à l'ouverture de la bibliothèque au runtime ?

Martial, j'ai lu ton topic en diagonale et d'apres ce que j'ai lu, j'ai cru comprendre que tu voudrai faire une sorte d'emulateur pour economiser de la ram (en faisant une extraction petit a petit du code a executer).
Or, je ne sais plus où, mais j'avait deja parlé de cette idée dans un topic et au final ce qui en est sorti c'est que pour economiser un peu de ram on se retrouve avec un systeme monstrueux...en ram
Donc c'est pas viable si c'est bien ca que tu veux faire
Par contre si j'ai mal compris... /me runsssssssss

Martial Demolins
: Bon, j'ai pensé à un truc tout bête: faire charger par le loader (forcément relogé) les adresses des fonctions de lib à utiliser, ou les valeurs des RAM calls concernés

Donc tu veux que ces programmes puissent avoir accès à des libs standard ? Je trouve ça un peu incompatible avec le but original (te débrouiller pour ne pas avoir plus de quelques 100aines d'octets de code en mémoire, mais utiliser une ou des libs de plusieurs ko).

Si.
Ce ne sont pas des traps, mais des "interrupt vectors"
C'est habituellement utilisé pour les interruptions [tiwiki]vectorisé[/tiwiki]es, mais il n'y en a pas sur TI. Ces vecteurs sont donc inutilisés (tu peux stocker des données dedans si ça t'amuse...enfin gaffe à la protection 600001,2 qui en couvre une partie.

Hum Bon courage alors
Ca doit etre faisable mais faut vraiment se prendre la tete dessus j'ai l'impression