Nouveau compresseur très rapide - Page 1

Salut à tous !

je vous présente la version béta de mon premier prog sur TI

Il s'agit d'un compresseur 'OnCalc' comme vous dites, et qui
a la particularité d'être très rapide et peu gourmand en mémoire.

Sur ma TI89 HW1, je l'ai mesuré à 24ko/s en compression, et 60ko/s en décompression.
Il nécessite environ 16ko pour la compression + le fichier bien sûr, et presque
rien pour la décompression, gros avantages pour les petites mémoires de nos calculatrices
Le taux de compression reste correct.

Il est actuellement compilé pour PedroM, et sauf demande particulière, je n'envisage pas
d'en faire une release pour l'AMS.

Vous pouvez le télécharger ici v0.3 :
Me contacter

Comme je ne l'ai pas encore terminé, il ne travaille que sur les fichiers en RAM,
je ne sais pas encore comment gérer les fichiers en Flash.

Et c'est donc là que commence mes questions lol :

Comment mesurer le temps d'éxécution en C ?
Pour l'accès aux fichiers, j'utilise les fonctions : SymFindPtr et HeapDeref,
seulement, je ne sais pas quelles fonctions utiliser pour les fichiers archives ??

EDIT :

Nouvelle version proche d'une finalle si plus de bugs trouvés


Série STZ v0.x :

Vitesse de compression : 46ko/s
Vitesse de décompression : ~120ko/s
Mémoire requise pour la compression : 16ko
Mémoire requise pour la décompression : 0ko
Taux moyen : 45%

v0.4 : Me contacter
v0.6 : Me contacter

Série STZ v1.x :

Vitesse de compression : 55ko/s
Vitesse de décompression : ~125ko/s
Mémoire requise pour la compression : 16ko
Mémoire requise pour la décompression : 0ko
Taux moyen : 45% (++)

v1.0 : Me contacter
v1.0b : Me contacter
v1.1 : Me contacter
v1.1a : Me contacter


Série STZ v2.x :

Vitesse de compression : 24ko/s
Vitesse de décompression : 33ko/s
Mémoire requise pour la compression : 16ko
Mémoire requise pour la décompression : 16ko
Taux moyen : 46%

v2.0 : Me contacter


Série STZ v3.x :

Vitesse de compression : 12ko/s
Vitesse de décompression : 30ko/s
Mémoire requise pour la compression : 16ko
Mémoire requise pour la décompression : 16ko
Taux moyen : 52%

v3.0 : Me contacter

Comment mesurer le temps d'éxécution en C ?

Il faut utiliser les timers intégrés dans la machine, qui sont accessibles par interruptions (donc il faut utiliser des handlers d'interruption dans ton programme).
Sur les calculettes HW2 et plus (toutes celles qui ont été produites depuis 1999), l'interruption #1 (AUTO_INT_1) est un timer 256 Hz assez précis. Il y a aussi l'interruption #5 (AUTO_INT_5), qui est un timer programmable jusqu'à 8192 Hz.
Tout ça est dans le header intr.h: PRG_* pour le timer programmable, le reste pour les interruptions.

seulement, je ne sais pas quelles fonctions utiliser pour les fichiers archives ??

EM_moveSymFromExtMem, EM_moveSymToExtMem (vat.h).

Génial ! Merci Lionel

Ca marche impec avec les archives maintenant !!

Est-ce que l'interruption #1 est aussi valable pour une HW1 ?

Elle est moins valable, parce que son taux de déclenchement n'est pas très précis (on donne habituellement les valeurs 350-395 Hz).
Mais bon, ce modèle de calculettes ayant disparu depuis dix ans, il ne faut pas s'en soucier plus que de raison

lol, mais euh, je te signale que je suis justement en possession d'une HW1 lol
Et le int 5 ? Avec une HW1 je peux ?

Ah oui, j'avais pas fait attention dans ./1
Là, il est raisonnable de se soucier des HW1 ^^

Sur une HW1, l'AUTO_INT_5 n'est pas plus précise que l'AUTO_INT_1 ou l'AUTO_INT_3 (que je n'avais pas mentionnée parce qu'elle ne se déclenche qu'à ~1 Hz), puisque les trois utilisent le même oscillateur comme base de temps...

on peut pas faire symfind pour un fichier en archive?

Et oui, on est pas tous au top de la modernité lol

Y'a un truc que je pige pas dans la doc de TIGCC, c'est que je ne trouve
pas la valeur de OSC2 ??

Quand on fait un PRG_setRate, il faut indiquer une valeur entre 0 et 3,
mais une des formules est par exemple :

defaut : OSC2/2^9

Mais ca vaut quoi OCS2 ?

J'aimerais le régler pour avoir une précision au centième de seconde voire au pire
au dixième.

squalyl (./7) :
on peut pas faire symfind pour un fichier en archive?

Oui, on peut, mais le pb c'est ensuite pour enregistrer les datas que ca bloque
Là il me faut obligatoirement des instructions spécifiques à la Flash

C'est une vieille version (il y en a une plus récente dans TIEmu, par exemple - faudrait que je la remplace), mais elle explique quand même ce qu'est OSC2: http://tict.ticalc.org/docs/J89hw.txt

stfox: ok

Petite mise à jour de STZ posté

Ta technique de compression serait beaucoup plus exploitable si tu sortais ça sous forme de code source réutilisable. Parce que l'exécutable, ce n'est pas pratique du tout pour utiliser ta méthode dans d'autres programmes.

C'est son droit de garder le code source pour lui

Et même s'il a vraiment envie de garder le code pour lui et qu'il utilisait un obfuscator: tu sais qu'il n'existe pas d'obfuscator parfait (c'est bien pour ça que tu ne t'es pas foulé pour la protection de HW3Patch), et tu sais aussi que l'assembleur 68k est assez lisible. En d'autres termes, si tu veux vraiment le source, tu peux le reconstituer

Lionel Debroux (./14) :
C'est son droit de garder le code source pour lui

Là n'est pas le sujet (il y a d'autres topics pour cette discussion).

Le fait est que cette routine de compression serait beaucoup plus utile si fournie de manière réutilisable, et la meilleure solution pour ceci est d'avoir un .a (une lib statique) avec le code source qui va avec. (Comme TIGCC ne fait aucune garantie de compatibilité binaire, publier un .a sans les sources est une très mauvaise idée. Plusieurs .a publiés sans code source ne fonctionnent plus, soit à cause de changements dans TIGCCLIB, soit à cause de changements dans le matériel et/ou logiciel des calculatrices.)

De plus, les sources pourraient aussi être adaptées aux besoins du programme qui utiliserait la routine.

Là n'est pas le sujet (il y a d'autres topics pour cette discussion).

Hmm, qui a introduit le sujet de la fourniture des sources dans ce topic ?

Je suis d'accord que c'est mieux quand les sources sont fournis, pour les raisons que tu as citées. Mais c'est lourd de te voir tout le temps introduire ce sujet...

J'ai cité des raisons purement pratiques, c'est toi qui as introduit le concept philosophique de droit.

Et quelque pars, je trouve qu'il a raison de ne pas fournir les sources

Si j'ai commencé la série de compresseurs STZ, c'est d'abord pour me familiariser
avec la programmation sur TI en C dans un premier temps, puis après avec le 68k

Et comme c'est un premier jet, je pense pas que ce soit interessant que je fournisse dans l'immédiat
des sources probablements buggués, ca viendra si on m'en fait la demande, et une fois
stabilisé tant qu'à faire
Faut savoir que pour celui qui cherche un bon compresseur, on trouve des centaines d'algos
voire de sources C sur le net plus ou moins adaptés à la TI, et dans STZ je n'ai rien inventé

Après, connaissant pas très bien l'univers TI, je ne sais pas qu'elle est la coutume
pour ce genre d'utilitaires : une librairie ? un prog indépendant ? ....
Il semblerai quand même que ce soit plutot des librairies en général, mais je ne sais
pas en créer, sauf si qqun a une doc sous la main ?

Je voulais un compresseur 'classique', car j'ai rien trouvé qui ne m'ait 'séduit'
dans ce qui existait
Les algos utilisés sont très vieux, encore plus vieux que celui que j'utilise et qui a déjà 20ans !!!

A terme j'aimerai l'introduire en temps que 'drivers de compression' dans PedroM,
un peu comme je l'ai déjà fait avec un ami sur HP, et comme ca existe dans les systèmes
de fichiers sur PC.

Voilà pour la petite histoire

Celà dit, j'ai publié la série 1 de STZ, qui n'est pas compatible avec la série 0
car l'algo est légèrement différent.
D'autres séries sont à venir, avec des performances/contraintes différentes

Une question, quel est le rapport de vitesse sur TI entre un prog écrit en C et le même
en asm ?

Erf, le rapport peut être de 2:1, 3:1, 10:1, ou l'inverse Ca dépend énormément de la qualité de ce qu'on écrit, en asm comme en C. Mais pour quelqu'un qui écrit dans les deux langages, je pense qu'on peut gagner 30% de temps en asm. J'ai vu des trusc compilés à réveiller un mort.

Sinon, pour ton programme, pourquoi ne pas faire un soft indépendant, qui s'utilise en ligne de commande ? Parce que les libs, il y en a déjà, mais souvent sans front-end, donc faut programmer pour les utiliser. Celui qui ne sait pas faire l'a dans l'os.
A noter que la solution tip-top est d'écrire un front-end en ligne de commande qui utilise ta librairie dynamiquement, PedroM est fait pour ça. la solution state of the art étant d'avoir une lib sans smc, exécutée en flash
Faut exporter le symbole _library pour créer une librairie, mais aussi exporter une version (pas obligatoire, mais recommandé). Regarde la doc de PreOS pour en savoir plus (http://www.yatonet.com/t3/ , .../preos/sdk/doc/preos.txt et ramcalls.txt.

Je ne sais pas si tu saurais être intérésé, mais tu as le format Pack Archive qui est entièrement supporté par PedroM:

      Title: Pack Archive
     Version: 0.72
 Platform(s): TI-89, TI-92+, V200, TI-89 Titanium
      Author: PpHd
    Web Site: http://www.timetoteam.fr.st
      E-Mail: ppelissi@caramail.com
Release Date: See PreOs.txt

-----------------------------------------------------------------------------
What is a Pack Archive ?
-----------------------------------------------------------------------------
	
A pack archive is an asm program which has some special features :
  + It contains multiple files in one file (like TAR files).
  + Each contained files can be compressed by shrnklib, or ziplib, or a personnal program (like ZIP files).
  + Each file can be stored uncompressed.
  + The first file of the Pack Archive will be extracted and executed when you want to run the Pack Archive without losing RAM (The Pack archive will remain archived during the execution of the program). -It works either with Shell (TictEx, doors, pct, ...), either the Home Line command.
  + The kernel can access the files of a Pack archive just like normal files. So you can add and compressed your libraries in ONE file, and it will be transparent from a developper/user point of view).
  + A program can access the files of a Pack Archive by using exported kernel functions.


-----------------------------------------------------------------------------
How to create Pack Archive ?
-----------------------------------------------------------------------------

kpack program is an easy way to create pack-archive using shrnklib.	
It needs that tigcc is installed (even if it could work witout).
Just write in a command shell:
     kpack	infile1.9xz infile2.9xz ... output
	
Example:
	kpack	doors.9xz graphlib.9xz userlib.9xz filelib.9xz ziplib.9xz doorslib
Or	kpack	*.9xz stdlib
	
The first file of a pack-archive will be executed when you try to run it.
	
You can even add some files which are not compressed in the pack :
Example:
	kpack	sma.9xz !smadata.9xz sma
Just add '!' before the filename you don't want to compresse 
(The first file MUST be compressed !)	

You can even add the compressing library in the Pack (uncompressed of course).

-----------------------------------------------------------------------------
How to use other compressing libraries ?
-----------------------------------------------------------------------------

You can use any compressing kernel libraries using Pack Archive.
The library must export a function whose prototype is :
Input: 
	d0.w = index of section to extract
	a0.l = pointer to archive
Output:
	d0.w = Handle or H_NULL (Standard C)
Registers destroyed :
	d0-d2/a0-a1 (Standard C)

Then have a look at programformat.txt, and you just have to change :
	+ The compressing library name.
	+ The minimum version number.
	+ The function number.
Compress your data, and modify the asm program produced by kpack
(it doesn't erase it). Then recompile it.
	



-----------------------------------------------------------------------------
How to use zpack ?
-----------------------------------------------------------------------------
	
zpack is an equivalent of kpack.exe but on-calc.
It will compress the files and create a pack archive on-calc using ziplib.
(ziplib compressed less than shrnklib but it works on-calc !)
The syntax is 
	zpack("file1","file2",..."outfile")
outfile must not exist.
	
It provides the same thing than compressing with kpack (Auto-exec archive / compressed libs).
A very nice feature : Even if ziplib is compressed by shrnklib, it works ! Remember, it is transparent ;) How it works ? First, the Pack Archive calls the kernel and says that it want to execute the first file. The kernel finds it, and discovers it needs ziplib. It searches ziplib, and finds it inside another Pack Archive which is compressed by shrnklib. It searches shrnklib, relocs it, executes the right function, extracts ziplib, unrelocs and frees shrnklib. Then it calls ziplib (Relocs, executes the right functions, extracts the first file, unrelocs, and frees ziplib). Then it executes the program :) 
Complicated ? Maybe, but the kernel does the job for you ;)
	


-----------------------------------------------------------------------------
How to use zunpack ?
-----------------------------------------------------------------------------
	
zunpack is the contrary of kpack.exe and zpack.
It will uncompress the selected file.
You can uncompress either file compressed by ziplib or shrnklib.
The syntax is 
	zunpack("file1")
where file1 is the file to extract.
(It is the name of a file which is inside a Pack Archive. It is not the name of a Pack Archive.

Beaucoup plus d'infos se trouvent dans les répertoires kpack et zpack du sdk de preos.
Si tu veux, je peux détailles d'avantage.
PS: Lorsqu'on parle de library, on parle de dynamique library on calc.

Kpack est génial en effet !

* entre un programme C et un programme ASM exactement équivalents (même niveau d'éventuelle réutilisation de librairies externes), il y a un facteur 3 à 5 en faveur du C sur le temps de développement. C'est loin d'être négligeable

* l'approximation 80/20 indique que 80% du temps d'un programme est passé dans 20% du code, et cette approximation est assez juste (bon, ça peut être 70/30 ou 90/10, mais vous voyez l'idée) dans une large gamme de programmes. On peut obtenir des résultats favorables sur l'optimisation, tout en ne sacrifiant pas trop le temps de développement, en ne réécrivant que les morceaux critiques en ASM.
(ce deuxième paragraphe est également valable pour le C/C++ par rapport aux langages de script: voir Mercurial, écrit en Python, sauf les morceaux critiques en vitesse)

Sacrifier la beauté d'un programme à de vagues notions de temps de développement dans le cadre de la programmation amateur, c'est une véritable prostitution.

J'étais assez comme ça avant: j'ai passé beaucoup trop de temps sur tthdex, par exemple.
Mais force est de constater que c'est le temps qui nous manque le plus, à tous. Quand on a plus d'idées que de temps pour les implémenter, mieux vaut à mon avis faire les programmes aussi vite que possible, tout en se faisant plaisir

stfox (./1) :
Comment mesurer le temps d'éxécution en C ?

Sinon, mon petit programme time devrait peut-être faire l'affaire : http://perso.orange.fr/jackiechan68k/produits.htm

UP UP Petite mise à jour et ajout de 2 nouvelles séries !

Folco -> je suis pas sûr de comprendre, mais stz marche en ligne de commande, syntaxe : stz file

Sasume -> Merci, je vais regarder ca J'ai besoin en effet d'avoir quelque chose de précis comme chrono.

PpHd -> Génial ce truc !! C'est super interessant, à priori on peu y glisser des formats autres que zlib ! Où est-ce que je peux trouver plus d'infos sur KPack ? Car je ne parviens pas à trouver Preos sur ton site lol

Ben regarde dans la toute dernière niouze d'aujourd'hui, une nouvelle version encore plus alapointe vient d'arriver.

t3

Sinon, ya une rubrique "Downloads", tu y trouveras ton bonheur.

Ah oui, faut télécharger les sources, c'est dans preos/sdk/kpack/

Merci Folco, j'avais pas vu !

stfox (./27) :
PpHd -> Génial ce truc !! C'est super interessant, à priori on peu y glisser des formats autres que zlib ! Où est-ce que je peux trouver plus d'infos sur KPack ? Car je ne parviens pas à trouver Preos sur ton site lol

Oui, n'importe quel format. Et il sera reconnue par le kernel (auto executable, librairies annexes gérées, etc).
kpack = Pack Archive au format shrnklib (On pc)
zpack = Pack Archive au format ziplib (On calc)

Et pour trouver les sources de Preos, regarde la dernière news.