Merci, c'est cool, et avec pedrom::tmpnam en moins, ça va diminuer la taille du loader trilove
avatar<<< Kernel Extremist©®™ >>>
Feel the power of (int16) !
Ceci dit, il n'y a pas des programmes qui supposent qu'ils ont une entrée en VAT ?
avatar<<< Kernel Extremis©®™ >>> et Inventeur de la différence administratif/judiciaire ! (©Yoshi Noir)

<Vertyos> un poil plus mais elle suce bien quand même la mienne ^^
<Sabrina`> tinkiete flan c juste qu'ils sont jaloux que je te trouve aussi appétissant
C'est bien pour ça que j'ai implémenté l'option -add. smile
(et même -arc pour un programme qui se la joutair PreOS trioui).
avatar<<< Kernel Extremist©®™ >>>
Feel the power of (int16) !
woops ! J'avais loader + partie principale qui faisaient 183 + 2245 bytes avant, et là ça fait plus que 141 + 1525 ^^ Bon, j'ai du virer 300 octets de texte.

Conseillez-moi : c'est utile d'implémenter un mode verbeux pour ce truc ? Je veux dire, tout est prêt pour ça, le switch et l'implantation, yaurait plus que les phrases à écrire, mais je laissais ce genre de détails pour la toute fin. Je me demande maintenant si c'est vraiment utile.

Avis ? smile
avatar<<< Kernel Extremist©®™ >>>
Feel the power of (int16) !
ça verboserait quoi?

tu peux faire une version "debug" avec le mode verbose activable, et une version "prod" sans le switch smile
L'état de l'avancement de la préparation du binaire, pour aider à localiser une éventuelle erreur. Mais je crois que le soft est trop simple pour ça. Et j'ai prévu une erreur claire partout où ça peut déconner (j'ai donc déjà 15 codes d'erreur). Le coup de la version debug, pourquoi pas, à voir. Le pire est que j'y ai pensé hier, mais pour PreOS, quand je traçais le linker hier, ça aurait bien aidé. grin

ErrorStrings:
Error0:		.asciz	"No arguments"
Error1:		.asciz	"Not enough RAM"
Error2:		.asciz	"Bad syntax :"
Error3:		.asciz	"Unknown option :"
Error4:		.asciz	"Missing argument after :"
Error5:		.asciz	"Inconsistent options :"
Error6:		.asciz	"Option needs another one :"
Error7:		.asciz	"No source file or immediate value to exec"
Error8:		.asciz	"Invalid filename :"
Error9:		.asciz	"File must be a text :"
Error10:	.asciz	"Size of hexa string is odd"
Error11:	.asciz	"File not found :"
Error12:	.asciz	"Invalid hexadecimal string"
Error13:	.asciz	"Can't create file :"
Error14:	.asciz	"Can't archive file :"

StrFatalError:	.asciz	"ERROR : %s %s %s\n"
avatar<<< Kernel Extremist©®™ >>>
Feel the power of (int16) !
(t1 ce fidebaque en 15 jours trioui)
avatar<<< Kernel Extremist©®™ >>>
Feel the power of (int16) !
Ca marche pas© !
avatarProud to be CAKE©®™
The cake is a lie! - Love your weighted companion cube

->986-Studio's Wonder Project!<-
yN a cassé ma signature :o
grin
avatar<<< Kernel Extremist©®™ >>>
Feel the power of (int16) !
raaaah ça va bientôt cartonner très fort love O4jb

Ca remarche après deux mois d'optimisation (ben oui, coder le soir à l'hôtel sur le code imprimé, c'est pas génial), une division de la taille par deux, et pas encore de bug trouvé.
avatar<<< Kernel Extremist©®™ >>>
Feel the power of (int16) !
Content pour toi.
C'est avec une RC de PedroM 0.82 ?
La dernière, la RC4. Ca prend maintenant en charge les strings, en plus des fichiers textes.
avatar<<< Kernel Extremist©®™ >>>
Feel the power of (int16) !
J'ai un souci avec l'archivage : quand j'archive le fichier avant de l'exécuter, PedroM refuse de le lancer : "Not a program" Il s'arrête au niveau de kernel::exec. Mais il est bien créé et archivé (ls -l confirme). Si je le lance juste après en ligne de commande, il marche. Voici mon script :
:> eexec -arg 4e444e750000 -add off -arc
Error (not a program)
:> ls -l
eexec 1335 0000 F3 008dc8
off   0007 0200 F3 4a0014
:> off
=> extinction !


Voici mon code pour archiver, puis lancer le programme (a2 est un SYM_STR* sur "off", d4.w le handle du programme) :
	pea.l	ERROR_FRAME(%fp)			|*frame
	RC	ER_catch
	tst.w	%d0
	beq.s	HandlerSet
		moveq.l	#ERROR_ADD_SYM,%d7
		bra	ThrowError
HandlerSet:
	pea.l	(%a2)					|ok, we can add it
	RC	SymAdd					|create symbol
	move.l	%d0,(%sp)				|push and test its HSYM
	beq	ThrowError				|shit...
		RC	DerefSym			|get SYM_ENTRY *
		move.w	%d4,12(%a0)			|and store handle
		RC	ER_success
		bset.b	#FLAG_SYM_ADDED,%d6		|set success flag
		btst.l	#FLAG_ARC,%d6			|must archive ?
		beq.s	ExecuteFile			|no, can execute file now
			moveq.l	#ERROR_ARC_SYM,%d7
			clr.l	(%sp)			|no HSYM
			pea.l	(%a2)			|but SYM_STR *
			RC	EM_moveSymToExtMem	|push it in archive
			tst.w	%d0			|success ?
			beq	ThrowError		|no

|===============================================================
|
|	Now run the file ! No protection, no register saved etc, the kernel handles that.
|
|===============================================================
ExecuteFile:
	btst.l	#FLAG_NORUN,%d6				|dry run ?
	bne.s	Quit					|ok, quit now
	move.w	%d4,%d0					|handle, arg of kernel::exec
	jsr	KERNEL_EXEC(%fp)			|go !


Que pasa ? confus sad

(puis j'aimerais bien résoudre ça, je sors une bêta quand c'est fixé, j'ai plus que de l'optimisation à faire (parce que j'ai encore réécrit 50% depuis la dernière fois grin))
avatar<<< Kernel Extremist©®™ >>>
Feel the power of (int16) !
jsr	KERNEL_EXEC(%fp)			|go !

Je sais pas, je connais pas la variable, mais je verrai bien plutôt
move.l KERNEL_EXEC(%fp),%a0
jsr (%a0)
Non, parce que ça marche le reste du temps, y aurait pas cette erreur, et c'est initialisé comme ça :
	move.w	#0x4EF9,%d0				|jmp xxx.l opcode (used three times)

	clr.w	-(%sp)					|first bytes of SYM_STR_FRAME. In fact, only the first one must be null
	move.l	(%a0)+,-(%sp)				|&kernel::exec
	move.w	%d0,-(%sp)				|jmp ...
	move.l	(%a0),-(%sp)				|&kernel::LibsExec
	move.w	%d0,-(%sp)				|jmp ...
	pea.l	(%a1)					|&return adress of the loader
	move.w	%d0,-(%sp)				|jmp ...
	movea.l	%sp,%fp					|then set the frame pointer
avatar<<< Kernel Extremist©®™ >>>
Feel the power of (int16) !
Folco (./43) :

Que pasa ? confus.gif frown.gif


Suite à l'archivage, l'handle de ton programme a changé. Cf source de EM_moveSymToExtMem
Hein ?!? Ok. Donc faut refaire un move.w 12(SymFindPtr(off)),d0

Merci !
avatar<<< Kernel Extremist©®™ >>>
Feel the power of (int16) !
Je ne suis pas sûr que ca soit la bonne ligne d'instruction, mais c'est l'idée. smile
Oui ok grin
avatar<<< Kernel Extremist©®™ >>>
Feel the power of (int16) !
		; Find a free Handle
		jsr	HeapGetHandle	; Yes, we don't keep the same handle after archiving the file.
		move.w	d0,d4
		beq.s	\Error

C'est pô mignon ça embarrassed

(et puis bordel ça a l'air compliqué d'écrire en flash sick)
avatar<<< Kernel Extremist©®™ >>>
Feel the power of (int16) !
A noter que théoriquement, si un GC s'effectue, ton addresse SYM_ENTRY * est suceptible de bouger aussi, donc un derefsym est aussi nécessaire... #ange#
Folco (./50) :

C'est pô mignon ça redface.gif


Patch wellcome.
Bon pour le patch, euh... j'ai des priorités on va dire tripo J'imagine qu'une simple modification de la table des handles suffirait pas, sinon t'aurais fait comme ça.
PpHd (./51) :
A noter que théoriquement, si un GC s'effectue, ton addresse SYM_ENTRY * est suceptible de bouger aussi, donc un derefsym est aussi nécessaire... #ange#

Ben vu que j'utilise un SYM_STR * en ram, ça devrait pas poser de problème, si ?


edit -> OUEEEEEEEEEEEEEEEEEEE ça marche !!!!!!!!!!! calin
avatar<<< Kernel Extremist©®™ >>>
Feel the power of (int16) !
Folco (./53) :
Ben vu que j'utilise un SYM_STR * en ram, ça devrait pas poser de problème, si ?


EM_GC recopie en RAM via HeapAlloc / HeapFree avant de recopier en Flash. Donc voilà ca peut bouger car la heap de la RAM peut se compresser... donc ton pointeur peut devenir invalide.
Ah ok, en effet, merci pour l'info. Mais dans mon cas, ça m'étonnerait quand même que le GC de la RAM puisse modifier la place de la pile (là où le trouve la SYM_STR). ^^
avatar<<< Kernel Extremist©®™ >>>
Feel the power of (int16) !
Bon, donc première beta de EExec (Extended Exec). Renommé car PedroM Exec ça fait un peut-être un peu pompeux, et ça n'a rien d'officiel. Mais c'est toujours pareil.

Extrait du readme et du changelog :
readme.txt

Run the program
---------------

Just send the binary file. It would
be better to archive the file to avoid RAM consumption. Then type
:>eexec <options> -arg <hexadecimal value>
:>eexec <options> -src <folder\>filename
options :
	-add <filename>
		add the file to the vat. the filename can contain a path.
		By default, eexec executes the code from RAM without
		adding it to the VAT.
	-arc	archive the file before running it. -add <filename> must have
		been specified.
	-rem	remove the file after having run it. -add <filename> must have
		been specified.
	-norun	don't run the argument value. It will be added to the VAT if
		specified. Will do nothing if the file isn't added, but you will
		be sure that your hex value is valid if no error is returned.
	-src <filename>
		use the specified file to get the hex value. It must be a
		text or a string file.


Tip
---

When run archived, this program uses only 129 bytes of RAM. Nice, isn't it ? ;)

History.txt

19-07-2009
----------
- first beta release
- added support of STR files as input
- removed -h switch : 'eexec' without any argument now displays a short help
- reduced a lot the size : 129 bytes for the loader, <1ko for the main part
- updated the pack archive to the standard, now it contains files : author, version,
  comment and icon
- increased reliability by using the ER_catch/ER_success romcalls
- EExec now supports adding/archiving/removing binary files when using a source
  file as input (STR or TEXT)
- updated sources to be more GPL-compliant
- add a tpr file and a .bat file to build easily the pack under MS-Windows
- verbose mode support removed (useless)
- kept only critical error messages
- renamed the soft


Si jamais vous avez du temps à perdre sur votre bonne vieille TI, n'hésitez pas à tester. A priori, trâce au débogage de ce soir, toutes les options proposées sont devenues fonctionnelles et sont vérifiées.
La release finale arrivera quand les ramcalls en fline arriveront. cheeky
D'ici là, je peux encore paufiner le code, ya deux-trois registres qui se sentent un peu oubliés.

Voilà, téléchargement. smile

ps : merci à tous ceux qui m'ont aidé !
avatar<<< Kernel Extremist©®™ >>>
Feel the power of (int16) !
On me dit "Type man eexec for more info"
mais lorsque je le fais, j'ai droit à Error (Syntax)
smile

(Bon sinon, je suis pas allé très loin mais ca à l'air de bien marcher).
Ahem gnimod

(j'ai commencé à coder man ya moins de deux heures grin)
avatar<<< Kernel Extremist©®™ >>>
Feel the power of (int16) !
Folco (./56) :
La release finale arrivera quand les ramcalls en fline arriveront. mod.gif


Hum, hu, ho, ha ?
Folco (./58) :
(j'ai commencé à coder man ya moins de deux heures biggrin.gif )


Il est où le topic ? gni
Les RAM_CALLs sont tous obsolètes et/ou inutiles. On peut parfaitement écrire ses chaînes Exec sans en utiliser. Cf. aussi http://www.tigen.org/kevin.kofler/ti89prog/ramcalls.txt.
avatarMes news pour calculatrices TI: Ti-Gen (fr/en), MobiFiles (de)
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é