Argh :/
Ça va alourdir un max si on se retrouve avec des mini-kernels dans chaque prog.
si on veut utiliser ce genre de spécificités, je me demande si cen'est pas mieux de coder directement en kernel.
Le code de relogement prend 50-250 octets selon les options (relogements non-redondants (le format AMS étant redondant pour éviter le dérelogement)? BSS? ROM_CALLs par relogement? relogements compressés (qui nécessitent une routine de décompression, évidemment)?). Le header+stub kernel prend 50-100 octets. Le kernel prend au moins 3 KO. Faites vos calculs...
C'est marrant quand même que tu critiques autant le kernel, mais que tu sautes quand même sur l'occasion d'élargir le _nostub à quelques fonctionnalités du kernel.
Lionel Debroux Le 03/08/2003 à 10:52Edité par Boo le 03/08/2003 à 12:19 > C'est marrant quand même que tu critiques autant le kernel, mais que tu sautes quand même sur l'occasion d'élargir le _nostub à quelques fonctionnalités du kernel.
Pour bien mettre les choses au point (ça aurait été pareil avec n'importe qui, dommage que ça soit toi): LE KERNEL N'A PAS QUE DES INCONVENIENTS ! IL Y A DE BONNES IDEES DEDANS !
Ca n'est quand même pas la première fois que je le dis, je l'ai dit sur notre forum aussi.
Un gros inconvénient est la place prise par le kernel lui-même, toutes ses librairies, le poids du passé, que n'a pas le _nostub... Et rien de ce qui n'est faisable en kernel n'est infaisable en _nostub, des choses sont infaisables en kernel mais faisables en _nostub.
En _nostub, on a du code redondant, mais on se passe de programme additionnel (si le programme est compressé, un launcher est créé, il suffit de lancer le launcher spécifique ou le launcher générique - l'argument selon lequel il faut un programme additionnel n'est pas valable).
Si on fait un truc non natif mais utile / pouvant être utile notamment pour diminuer la taille (SAVE_SCREEN, EXIT_SUPPORT, table de relocations compressées, peut-être tables de relocation kernel, mais en revanche pas vraiment à mon avis les BSS, dont la facilité d'utilisation est là pour cacher une certaine paresse - il est trivial de tout faire soi-même), on l'implémente dans le programme.
Le shared-code en _nostub serait possible pour certains trucs, mais il faudrait que tous les auteurs de programmes l'utilisent - ce qui est loin d'être gagné. Et puis, ça va créer des problèmes qu'on n'a pas avec des libs statiques:
* perte de place, même en restreignant au maximum les fonctions - restriction du nombre des fonctions qui ferait inévitablement des jaloux qui ne manqueraient pas de se plaindre parce que leur truc n'y est pas, etc.
* problèmes d'update: vieilles versions qui traînent, incompatibilités des nouvelles versions avec les anciennes s'il a fallu changer de façon imprévue un truc important - ceci est évité par une modification et recompilation du programme. Que se serait-il passé si Complib avait été en lib dynamique, et que le bug ait été vu après qu'elle ait été utilisée à grande échelle ?
* nécessité d'avoir un programme additionnel pour faire marcher un programme _nostub même simple et pas trop gros, ça n'est pas bien...
Les libs dynamiques ont elles aussi des avantages, il y a des fois où on ne peut faire sans (FAT-Engine notamment, et le contournement de la limite des 64 KB).
Le shared-code est possible avec les FlashApps (un programme ASM doit bien pouvoir s'en servir ?), mais disponible seulement sous AMS 2.xx...
[EDIT: j'ai mis un long moment à écrire ce post, je n'avais pas vu le post de jackiechan.]
[EDIT2: il faudrait aussi se mettre d'accord sur ce qu'on appelle _nostub. Si on appelle _nostub tout programme qui rentre directement sur _main, dans ce cas-là, ça fait très longtemps qu'il n'y a presque plus de _nostub... En revanche, si le _nostub est tout ce qui tourne sans kernel, alors il y en a énormément.]
[EDIT3: le but de ce post n'est pas de lancer un débat kernel/_nostub].
Le fait que ce soit par défaut, fait que ça nous rajoute du start-up code même si on n'utilise pas de section BSS ?
Ah, vous ne pouvez pas fixer un seuil à dépasser en taille pour que ce soit utilisé dans des BSS ?
D'ailleurs, je ne comprends pas pourquoi on ne peut pas faire de références PC-relative avec des BSS, puisqu'au moment du relogement, on sait à quelle adresse est située on doit faire la référence (donc la valeur du PC) et on sait à quelle adresse on fait référence donc on peut faire la différence des deux non ?
Les offsets PC-relatifs sont de 2 octets, donc limités à -32768 ... 32767.
Et puis ton idée demanderait quand-même un relogement, alors que tout l'intérêt du PC-relatif est d'éviter le relogement.
OK, merci.
Pour l'intérêt du PC-relatif, personnellement, si je l'utilise, ce n'est pas seulement pour éviter un relogement, mais c'est que ce mode d'adressage est plus rapide que l'adressage absolu long (et plus petit).
Mais c'est le cas exactement parce que c'est limité à ±3276[78].
2. Tu mets quand même un include "tios.h" ? Tu assembles avec quoi ?
3. Il faut le code entier, ou bien plus d'infos sur le crash. Penses-tu à restaurer la pile après l'appel du ROM_CALL ?
2. non, c'est vrai, je ne met pas d'include "tios.h", vu que je ne fait aucun appel au header, mais peur-être le faut-il ???? je vais essayer.
3. Le code, je l'ai pompé directement sur un exemple d'un tuto.
Le crash il n'y en a pas, j'ai juste le "crash intercepted" de PreOS dans la status line.
Quant à la pile, oui, je la restaure.
Et à la fin du prog, tout remarche normalement, sauf que j'ai perdu 200 octets à cause du hot-reset
3.Oui, mais il faut plus d'infos sur le type crash, bien qu'il ait été intercepté c'est un crash.
Et il nous faut ton code complet si tu veux qu'on t'aide.
tu l'as installé comment tigcc ?
Que cache le pays des Dieux ? -
Forum Ghibli -
Forum LittéraireLa fin d'un monde souillé est venue. L'oiseau blanc plane dans le ciel annonçant le début d'une longue ère de purification. Détachons-nous à jamais de notre vie dans ce monde de souffrance. Ô toi l'oiseau blanc, l'être vêtu de bleu, guide nous vers ce monde de pureté. - Sutra originel dork.
Pour la première question, je ne sais pas, c'est bizarre. Tu essaies de compiler à partir de l'IDE ?
mon frangin me l'a gravé sur cd, mais c'est pas le zip qu'il m'a passé, du coup je suis sur de rien.
pourtant tout s'est bien passé à l'installation, mais je répète, je pense que le pb vient de là. je vais graver le zip d'origine et tout réinstaller
Donc pour être sûr, il vaut mieux utiliser -mno-bss (ou au moins -fno-zero-initialized-in-bss, mais c'est moins sûr).
