Augmenter la RAM de toutes les HW2 sans bidouillage hardware ? PpHd - Page 1

En potassant un peu une documentation sur les ports de la HW2, j'ai vu qu'un certain Monsieur $700012 était capable (si on le lui demande gentillement et d'une manière très précise) de permettre l'exécution de programmes situés en ROM !

... donc d'augmenter la RAM disponible pour les besoins des programmes d'exactement taille_du_programme octets ! Imaginons un jeu qui fait 40 ko : ça lui fait 40 ko de RAM en plus de disponible

Allez PpHd, fout-nous cette fonctionnalité dans PreOS, et t'es sûr que tous les nostubiens se convertiront au kernel !!!
(Pas de débat N/K dans ce topic SVP )

-

Y'a des docs (sûrement très regrettées par TI ) qui traînent sur le net.

Un port c'est une adresse qui n'est pas en RAM, mais sur un composant quelconque.
Par exemple le port I/O : c'est un composant qui est "branché" à l'adresse <j'ai la flemme d'aller voir laquelle dans ma doc>

Donc un port s'utilise comme la RAM, sauf qu'on n'accède pas du tout à la RAM mais aux entrées d'un composant


Et là, voici venir la notion de Haute Impédence, qui s'étudie en STI électronique dès la classe de 1ère

yup, mais c comme qui dirait un peu chiant du point de vue des relogements (PIC, sans romcalls, ramcalls ou BSS... en gros du nostub en plus contraignant )

en plus il faut que le prog fonctionne aussi sur HW1, donc c viable pour un prog qui demanderait sans cette méthode 180 ko de RAM, et qu'il ne demande donc que 140 ko sur HW2...

Merde quel con j'avais pas pensé aux relogements !! Ha oui c'est la merde....

Remarque, non à chaque lancement du programme, le kernel regarde si le programme n'a pas été délogé (autrement dit : il y a eu un garbage collection), et s'il n'a pas été délogé, y'a rien d'autre à faire que de lancer le prog, sinon ben on re-reloge

Le seul obstacle que je vois, c'est pour le relogement : il paraît qu'on ne peut pas écrire ce qu"on veut en ROM car il n'y a que 2 actions possible sur la Flash :
1- effacer tout un bloc (c'est à dire mettre tout le bloc à 1)
2- mettre à zéro les bits qu'on veut

autrement dit : on reprogramme les FlashApps ça doit être assez chiant à programmer (d'autant plus qu'il faudrait vérifier que le prog est en mémoire basse sur HW1, ie en dehors des 384 ko standard d'archive), et les progs existant n'en bénéficieraient pas...

Il faudrait aussi gérer le multi-section dans les fichiers .o (i.e. segments data/text/bss), donc c vraiment pas très cool

Ben si en fait tient c'est pas un pb !

Un bloc ce n'est que 64 ko !
- on le copie en RAM
- on réalloue le prog dans ce bloc en RAM, mais en utilisant les adresses du bloc en ROM
- on efface le bloc
- on recopie le buffer en RAM corrigé dans notre segment !

>> les progs existant n'en bénéficieraient pas

ben si ! et même les progs nostub ! je crois que tu n'as pas bien compris mon idée, relit tout

mais pour éviter ces 64 ko de RAM, il faudrait intercepter les garbage collections, et empêcher la copie du programme dans le secteur, en remplaçant les relogements par des -1, et ensuite à l'exécution reloger le prog si ce n'est pas déjà fait...

d'autant plus que si toutes les bibliothèques dynamiques utilisées ne respectent pas ce format, elles doivent être copiées en RAM : pb puisqu'il faudrait faire une relocation flash à chaque exécution du prog, ce qui peut très très vite niquer la Flash (pour peu que ce soit un prog du genre flib, qui risque d'être appelé en continu en quittant à chaque fois juste après)

Et si on ne reloge pas à chaque exec, ça pose aussi des pb pour les BSS et pour les données en RAM...

En gros : c la merde

>> d'autant plus que si toutes les bibliothèques dynamiques utilisées ne respectent pas ce format
Quel format ? y'a aucun format spécial à définir

Les BSS : ha oui

Ben si, format sans BSS, et qui ne peut pas écrire dans le prog (ie pas de variables globales, juste des malloc et des passages de paramètres , ou sinon des variables globales dans un segment différent - .data -), c pas très compatible

Sinon pour gérer les BSS et le .data, il faudrait que le prog puisse accéder à une adresse fixe pour chaque garbage collection pour déterminer l'adresse des BSS et du segment data... Donc il faudrait faire des $C8-like pour les sections BSS et data, bref c presque pire que du nostub

mais c archi lent la ROM !!!

S valable aussi sur HW1. Mais il faut deproteger l'acces a ces ports !
Et comme dit Pollux, la programmation de ces trucs est TRES chiante.

Je confirme ce que dit PpHd (pour une fois ).

>S valable aussi sur HW1.
En effet. Le code pour la désactiver la protection anti-exécution est différent, mais ce n'est pas un vrai problème.

>Mais il faut deproteger l'acces a ces ports !
En effet.

>Et comme dit Pollux, la programmation de ces trucs est TRES chiante.
Oui. Il faudra au minimum attendre la bêta 19 de TIGCC et son switch -mno-merge-sections.

Thibaut a écrit :
Allez PpHd, fout-nous cette fonctionnalité dans PreOS, et t'es sûr que tous les nostubiens se convertiront au kernel !!!

Non, je foutrai la même fonctionnalité dans ttstart.
Mais je ne suis pas trop fasciné par cette idée parce que ça implique une déprotection des ports I/O système et donc de la protection Flash/IO.

Et les reloc sont tres chiantes. Donc

Kevin> -mno-merge-sections
un bête script VB dans Visual Studio (support des regexp) peut faire la même chose

Non, parce qu'on émet .data dans les 2 cas, donc tu ne pourras pas les différencier.

c ce que tu crois...

Encore une idée plus ou moins foireuse (plutôt plus que moins) de Monsieur Thibaut...
Remarque, c'est bien d'avoir des idées, mais encore faut-il qu'elles marchent.

Pourquoi ne pas exploiter les trous du début de la Flash, tant que vous y êtes ? Ca sera encore plus difficile à y écrire qu'en archive (EM_write lance une erreur, et FL_write ne fait rien car l'adresse n'est pas correcte).

Attendez j'ai une super idée... pourquoi ne pas ecrire sur le certificat...

XDanger : et après tu viens me dire que je cherche tout le temps à me foutre de ta gueule... t'es pas logique

Thibeau: faut dire que t'es quand meme un gas bisard...
tu te fout de la gueule de K. et apres tu lui pose des question d'asm...
De meme pour JM ..

En bref si t'arraitais de te prendre la tete..

arf je me suis foutu de la gueule de JM, c'est nouveau

T'es qqn qui utilise les personnes a but personnel.. mais moi je m'en fou et tu va me dire que tu t'en fou...

Tu pourrais expliquer ce que tu veux dire

En bref tu considéres une personne comme un objet, tu l'utilises qu'en t'en a besoin, et tu le jete quand t'n a pas besoin...

cf topics/15762-une-bibliotheque-graphique-puissante-et-pourtant-simple-dutilisation/10#291
:]

> XDanger : et après tu viens me dire que je cherche tout le temps à me foutre de ta gueule... t'es pas logique
Je m'attendais à ce que tu me reproches quelque chose (ce post était fait pour ça)...
J'ai proposé qu'on arrête de se critiquer mutuellement sans raison. Comme au bout de plusieurs posts je n'ai pas eu de réponse claire (peut-être que je me suis très mal exprimé, mais quand même), j'ai laissé tomber.

Reconnais quand même que je ne suis pas tout à fait pareil avec toi que TiMad (d'ailleurs, vous commencez sérieusement à me gaver, et je vois que je ne suis pas le seul dans ce cas-là). Kevin/PpHd se disputent à propos de leurs idées, mais pas en attaques personnelles.

Aprés la guerre Kernel/nosub, la guerre Thibaut/tout le monde

Ca fait un peut gamin de geuler sur tout le monde et de porter la faute sur les autres.
Agissez en adulte (ou essayez)