Nouveau compresseur très rapide - Page 3

stfox (./34) :
PpHd -> La même chose que lorsque que l'on active la compression de fichier dans le système de fichier NTFS
C'est à dire qu'à chaque opération de fichier: ouverture/fermeture, création, modification etc, celui-ci est automatiquement
compressé/décompressé, sans que l'utilisateur/application ne s'en soucis
Mais pour ca, il faut un compresseur spécifique pour que les ressources consommés soient minimales.

Folco -> Pour une large diffusion, encore faudrait'il qu'il y ai du public pour ca, or, si je ne m'abuse,
autant dans l'univers TI que HP la communauté se limite à une poigné de pationnés lol
Et j'aurais pas choisi de développer sous PedroM qui est d'autant plus exclusif niveau utilisateurs ....
Donc, pour la large diffusion, c'est déjà mort avant d'être né ...

Le principal but d'un drivers de compression, c'est justement d'être 'indolore' autant pour les
applications que pour l'utilisateur, c'est ni plus ni moins qu'une option à activer.
Les données 'vus' ne sont jamais les données compressées, donc le format de compression utilisé,
on s'en tape un peu beaucoup
Il faut se représenter ca comme une couche supplémentaire entre les applications (et donc l'utilisateur),
et les donnés.
De la même manière qu'on délègue au système d'exploitation la facon d'organiser les fichiers,
c'est le système qui s'occupe de compresser ou décompresser les fichiers suivant l'appel système.
Comme c'est le cas avec kPack et la décompression !

Ce que tu peux essayer de faire c'est voir du coté des fonctions de mise en Flash:
http://tigcc.ticalc.org/doc/vat.html#EM_moveSymFromExtMem
http://tigcc.ticalc.org/doc/vat.html#EM_moveSymToExtMem
http://tigcc.ticalc.org/doc/vat.html#EM_twinSymFromExtMem

ie. compresser automatiquement et à la volée si on archive le fichier, le décompresser autrement.
Mais ca ne gérera pas le cas d'un accès direct.
Pour çà le mieux et d'intercepter trap #3 + HeapDeref, et de faire un test pour désarchiver le fichier si c'est le cas (N'oublies pas de faire un cache pour redonner les entrées déjà compressés - utilise le système des twin pour le faire ).
Et il faudra après intercepter la sortie du programme pour libérer ces "fichiers" décompressées en RAM et que tu as décompréssé.
Tu peux meme penser à taguuer ton handle de facon spécial (bit de poids fort à 1) pour le reconnaitre de suite.

Si tu fais çà, ca pourra marcher à peu près sauf dans qqs programmes.
Mais tout le système de "hackage" du système est à faire en assembleur, pas en C...

Lol, il est hors de question que mes programmes marchent de cette manière, bonsoir la consommation de ressource.

il sert a quoi le trap 3 dans ce contexte?

Ah !!!!! Merci PpHd !! Enfin des paroles encouragentes, car jusque là je n'avais plus qu'à aller me faire
pendre avec mon idée

Bref, de toute façon je suis encore loin d'en être à modifier PedroM, car je n'ai pas terminé
d'explorer les différents algos de compression qui existent afin d'en sélectionner la crème

Celà dit, restez assis, car la version assembleur de STZv0.x décoiffe bien comme il faut,
c'est un sérieux candidat pour de la compression/décompression 'transparente'

Je vous laisse découvrir les résultats en page 1 !

Pour la petite histoire, je pense qu'on est très proche des vitesses maximum en décompression,
à la rigueur quelques optimisations de gens calés en assembleurs 68k pourrait améliorer
de quelques %, mais ca ne sera pas un facteur 2 ou plus, ca c'est sûr

En compression, il y a encore peut-être quelques trucs à faire, mais là je manque
sérieusement d'expérience, et ca risque de prendre du temps.
Il y a toujours la solution 'immédiate' d'utiliser l'algo qu'on a mis au point avec un amis
et qui est le plus rapide sur PC, mais le taux de compression reste assez faible.

La plus sérieuse piste d'amélioration reste le taux de compression pour cette même vitesse,
là y'a matière à faire, car il existe de bien beaux algos à découvrir !


Sasume -> Merci pour ton outils 'time' c'est excellent, il me permet de voir ce qu'apporte certaines
optimisations, mais malheureusement donne des temps erronés sur ma TI89 HW1
Par exemple pour STZ3, j'ai 2 secondes de plus en compression sur mon fichier test qui pèse 60ko.
Dommage, car les vitesses sont devenues telle que ca devient difficile de réaliser des mesures précisent lol

La vitesse c'est bien, mais qu'en est-il du taux moyen de compression?

Oui, effectivement, j'ai oublié de mentionner cette donnée importante
Je l'ai rajouté

squalyl (./63) :
il sert a quoi le trap 3 dans ce contexte?

Déréférencement. Mais ni stfox ni PpHd n'a expliqué comment utiliser ça avec un programme utilisant tios::deref vers un fichier archivé. Crash garanti à tous les coups.
Et ça empêche à chacun de faire exécuter le progrmme qu'il veut, ou il veut, comme il veut. Je pense évidemment à ma manière d'exécuter.

pour les fanas d'assembleurs qui comptent les cycles, je kiffe l'overhead du #trap qui passe en mode superviseur, change de pile, et tout le bordel

Ouais, mais tu déréférences en 4 bytes et plus en 6

move.w (handle),-(%sp)
.word 0xf800+HeapDeref*4
addq.l #2,sp

vs

movea.w (handle),%a0
trap #3

mouais

On est dans l'embarqué: l'optimisation taille, c'est TOUJOURS bien, même quand ça ralentit significativement

oui, et dans un truc encore plus embarqué qu'une TI, on me demande d'optimiser A LA FOIS en vitesse et en taille

oui, dans une javacard

Cette histoire du trap #3, ce serait pratique pour l'optimisation taille, mais malheureusement le système d'exploitation ne le propose pas (et en principe le trap est réservé pour l'utilisation future!) donc c'est une mauvaise idée de s'en servir.

Et d'ailleurs, si on exécute le programme sur un kernel moins récent, il va planter sans avertissement si on essaie d'appeler le trap #3.

si on exécute le programme sur un kernel moins récent

Supposition largement stupide de nos jours, comme tu le sais...
Ici, elle est off-topic (il s'agit de programmation PedroM)... à moins que tu comptes intégrer HeapDeref par trap #3 à TIGCC, mais ça serait surprenant, vu que tu ne veux pas upgrader le support kernel...

Heu... le trap #3 n'existe que sur PedroM et pas ailleurs... (Et Unios)

Donc c'est génial pour faire des programmes non-portables.

Non, c'est parfait pour les programmes PedroM-only.

(et tu vas pas me dire que c'et un travail monumental si tu veux faire un portage ^^)

./75: ah, je croyais que PreOS le proposait aussi.
./76: ça tombe bien, on parle justement d'un de ces programmes dans ce topic !

Ben, non, PreOS, le propose pas, et je trouve ça dommage. Surtout que comme dit, ça date d'Unios ...

Je vous sert quelque chose à boire ?

La barre fatidique des 50ko/s en compression est passée grâce à l'utilisation d'une nouvelle fonction de hashage
qui est la principale consommation de ressource, et hop +20%

Folco -> Peux-tu me dire ce que fait cette fonction dont tu parles 'tios::deref '
que prend-elle comme argument et que retourne t'elle ? Et ou se trouve t'elle ?

Ben je te conseille de regarder directement le header de tios.h, dans tigcc si ça a été ajouét par compatibilité, ou dans le header fourni avec les sources de PreOS, sur le site de la t3.

C'est une macro, tios::deref (ou DEREF) qui prend en argument un handle dans dn.w, et qui renvoie l'adresse associée dans an. Le choix des registres se fait donc dans l'écriture de la macro, dans ton programme. Et regarde dans le header, ya l'implémentation vu que justement, c'est une macro : ça va lire directement dans la table des handles.

---

Je t'explique tout de même pourquoi même si ton idée est en soi un excellent proof of concept, je ne suis pas fan (personnellement, et de mon point de vue à moi) :
Mes programmes sont composés de deux parties : un loader et une partie principale. Le tout enfermé dans un pack archive (cf doc de PreOS et Ramcalls.txt)), non compressé. La partie principale porte le flag kernel "read-only" (cf doc de PreOS, ProgFormatV4.txt), donc n'est pas relogée en RAM par le linker de PreOS pour être exécuté : il est exécuté là où il est.

Ce qui fait que par exemple, qu'un de mes programmes fasse 1 ou 10 ko (ou encore plus), il ne pèse que le poids du loader en RAM (ie entre 150 et 250 octets dûs aux appels relogés dont le programme a besoin). Le reste s'exécute en archive, le code étant intégralement PIC et utilisant un stack frame pour y stocker ses données.

Donc ton "driver" rendrait celà impossible, à moins que PpHd rende possible qu'un pack comme-ci comme-ça ne passe pas par ta moulinette.

DEREF, c'est un hack à vomir pour ceux qui ne veulent pas utiliser l'API documentée (HeapDeref), je déconseille absolument son utilisation. Aussi parce que ça coûte un relogement de RAM_CALL à chaque fois.

Et un DEREF en fonction ?

Je comprend bien ce que tu me dis.

Je crois que le problème est très simple :

Il y a 2 catégories d'applications :

- Celles qui veulent rester compatible avec un système et qui respectent les portes
d'entrées fournies par l'OS

- Celles qui contournent le système et qui donc prennent le risque de ne plus être
compatible à la prochaine mise à jour de l'OS

En clair, les applications qui shuntent l'OS, je ne m'en soucis pas, car ce n'est pas
moi qui les rendrais incompatibles, mais ce sont leurs concepteurs qui
ont délibérément pris le risque de ne plus être compatible avec les nouvelles
versions d'OS.

C'est le même cas de figure si demain TI sort un nouvel AMS avec une VAT légèrement
modifiée, tous les progs qui n'utilisent pas les portent d'entrée de l'AMS se verront
dans l'obligation au mieu d'être recompilé, voire qu'une partie du code soit ré-écrite,
et au pire ne pourrons plus marcher sans les revoir dans leur intégralité !

stfox (./84) :
En clair, les applications qui shuntent l'OS, je ne m'en soucis pas, car ce n'est pas
moi qui les rendrais incompatibles, mais ce sont leurs concepteurs qui
ont délibérément pris le risque de ne plus être compatible avec les nouvelles versions d'OS.

Euh... renseigne-toi un peu et lis les docs... je n'utilise que ce qui est documenté... Vas lire au moins les documents que je t'ai cité, je t'ai maché le travail.

C'est le même cas de figure si demain TI sort un nouvel AMS avec une VAT légèrement
modifiée, tous les progs qui n'utilisent pas les portent d'entrée de l'AMS se verrontdans l'obligation au mieu d'être recompilé

Faux (et impossible pratiquement). Renseigne-toi sur le fonctionnement.

stfox (./84) :
- Celles qui veulent rester compatible avec un système et qui respectent les portes d'entrées fournies par l'OS

Mes programmes font partie de cette catégorie. Je n'utilise que du documenté, et programme en kernel pour justement, utiliser une API puissante pour ne pas hacker.

En fait, tu avances beaucoup de choses, mais tu ne sais pas comment marchent PedroM et AMS.

Folco (./85) :
Mes programmes font partie de cette catégorie. Je n'utilise que du documenté, et programme en kernel pour justement, utiliser une API puissante pour ne pas hacker.

L'"API puissante" en question est une API hackée qui contourne les vraies APIs de AMS.

Et il y a plein de hacks dans PreOs.

Et alors ? PreOS sert à ça... D'ailleurs, ya aussi plein de hack dans TIGCCLIB, alors...

Oublié de répondre à ça ;

En clair, les applications qui shuntent l'OS, je ne m'en soucis pas, car ce n'est pas
moi qui les rendrais incompatibles, mais ce sont leurs concepteurs qui
ont délibérément pris le risque de ne plus être compatible avec les nouvellesversions d'OS.

PreOS est construit avec la philosophie inverse. Quand tu liras les sources, tu te rendras compte que c'est même documenté à chaque fois.

Ah oui, parce qu'encourager l'utilisation de GHOST_SPACE (RAM_CALL qui vaut 0x40000 ou 0x200000 selon le modèle) pour hacker les vecteurs d'interruptions est beaucoup plus propre et plus sûr pour le futur que faire le bclr qu'il faut pour les déprotéger. <-- ironie!

Je te signale qu'il y a aussi cette macro dans TIGCCLIB, et que PpHd ne va pas virer ce code autrefois safe pour des questions de compatibilité évidente. Quant à moi, je n'utilise pas ce ramcall.

Folco (./85) :

Faux (et impossible pratiquement). Renseigne-toi sur le fonctionnement.

La VAT ou autre chose peu importe c'était un exemple.
Qu'on ne me dise pas que les mises à jour passés du TI-OS n'ont jamais mis à
mal un seul programme qui ait prit le risque de passer outre l'API fournie ....

En fait, tu avances beaucoup de choses, mais tu ne sais pas comment marchent PedroM et AMS.

Ah bon ? Il suffit de lire les questions que je pose pour s'en rendre compte non ?
Si en l'espace de 2 semaines j'avais eu le temps d'écrire tout ces compresseurs
sur une plateforme inconnue, et qu'en plus je me serais documenté sévère sur ces OS au point d'en connaitre les moindres détails techniques, je crois que j'irai postuler direct à la NASA

Et pour tout le reste :

Un OS c'est un OS, même avec ses particularités, il doit rester le seul interlocuteur
pour les applis, ou alors il se condamne à ne pas pouvoir évoluer.