Kernel ou nostub ? - Page 1

-> topic pour rediriger les divers trolls d'autres topics... faut pas que ça dégénère non plus

trollons,
KERNEL POWAAAAA !
je laisse PpHd donner des arguments constructifs, c'est juste pour inaugurer le topic

(on parle de Kernel et de nostub ici naPO hein )

Il demarre tres mal ce troll. Ca motive pas.

erf, la supériorité du kernel serait tant évidente ?

Perso, je m'en fout

Windows ME sux

Kevin aime Windows ME

Kevin aime le nostub

-> nostub suxxxxxxxxx, kernel powa


cqfd

ouais enfin bon c'est pas une raison pour pourrir le topic gratuitement hein

Pas mal ton syllogisme, Vark

[edit : cross]

-

les avantages que je vois :
libs dynamiques : gain de place, compatibilité plus simple
EXTRA_RAM_CALL : simplicité de programmation en ASM
RAM_CALL : très pratique point de vue compatibilité : on rejette tous les hacks dans un seul programme, pour éviter de devoir mettre 50 progs à jour à chaque nouvelle AMS/HW
ROM_CALL : les appels nostub me conviennent déjà, faudrait voir si je peux gagner en place en utilisant les rom_call en f-line
bss : je n'en ai jamais eu besoin

bss: gain de place car pas besoin de faire un malloc / free + Possibilite de configurer le programme pour qu'a chaque relancement, le kernel
realloue un nouvel BSS menteur!

Que sont les extra_ram_call par rapport aux ram_call pas extras ?
En tout cas, je suis d'accord avec le fait que les libs dynamiques et les ram_calls sont intéressants.

-

Que sont les extra_ram_call par rapport aux ram_call pas extras ?

c'est des constantes spécifiques aux programmes, qui ont une valeur sur 89 et une valeur sur 92. Par exemple pour les touches ou des dimensions d'écrans qui ne sont pas dans les RAM_cALL déjà existants

Orion_> les RAM_CALL c'est soit des routines, soit des constantes fournies par le kernel, comme KEY_UP qui a une valeur différente sur 92+ et 89

-

Ou kernel::exec qui fonctionne sur toutes calcs.

oui
avant, je ne connaissais quasiment que les libs dynamiques, et c'est en faisant un désassembleur que je me suis rendu compte de toutes possibilités des programmes kernels

libs dynamiques : gain de place, compatibilité plus simple

EXTRA_RAM_CALL : simplicité de programmation en ASM

RAM_CALL : très pratique point de vue compatibilité : on rejette tous les hacks dans un seul programme, pour éviter de devoir mettre 50 progs à jour à chaque nouvelle AMS/HW.

ROM_CALL : les appels nostub me conviennent déjà, faudrait voir si je peux gagner en place en utilisant les rom_call en f-line

bss : je n'en ai jamais eu besoin

L'avantage du _nostub : supporté plus facilement par TIGCC/TIGCC IDE, et c'est non négligeable quand on est développeur débutant.

supporté plus facilement par TIGCC/TIGCC IDE

uniquement parce que c'est fait exprès, pour décourage les gens de programmer en kernel
enfin, c'est comme ça que je le vois, je me trompe peut-être
edit : rapetissement du troll ^^

Moi aussi je le vois comme ca

bon, les désavantages maintenant :
il faut installer le kernel à chaque reset
toutes les fonctions des libs ne sont pas systématiquement utilisées (mais normalement si la lib est bien foutue on ne perd pas trop de place)

Y'a un programme pour enlever, et je bosse pour que preos resiste au reset (sans modifier la flash. Trou ams powa).

> toutes les fonctions des libs ne sont pas systématiquement utilisées
A part pour les gros jeux, ca n'est pas grave. Mais dans ce cas la, la librarie est tout le temps tres utilisee.

supporté plus facilement par TIGCC/TIGCC IDE

Bah c'est clair que je le vois comme vous aussi :/

Sinon, j'aime bien que le kernel permette (en tous cas pour l'instant) la compatibilité avec les anciens programmes juste en touchant au kernel, pas aux programmes .

Ben non, Iceberg ne remplace pas GhostBuster, tu es quand-même obligé de patcher tes programmes pour la Titanium.

Sinon:
* Les librairies dynamiques obligent l'utilisateur à faire une partie du boulot du programmeur (récupérer les dépendances et les mettre à jour toutes individuellement) et à gaspiller de la place sur sa calculatrice pour des fonctions inutilisées.
* Les ROM_CALLs par relogement, on les a aussi sans kernel (code de démarrage), et puis de toute façon, les F-Line ROM_CALLs sont la meilleure solution.
* Les sections BSS, on les a aussi sans kernel (à l'aide du code de démarrage), elles aussi.

Mais bon, le code de démarrage, c'est un micro kernel, hein.

* Les librairies dynamiques obligent l'utilisateur à faire une partie du boulot du programmeur (récupérer les dépendances et les mettre à jour toutes individuellement) et à gaspiller de la place sur sa calculatrice pour des fonctions inutilisées.

elles sont en général fournies avec le programme. Et c'est pas beaucoup plus dur de mettre 3-4 programmes qu'un seul

Ben non, Iceberg ne remplace pas GhostBuster, tu es quand-même obligé de patcher tes programmes pour la Titanium.

pour tous les programmes ?

* Les ROM_CALLs par relogement, on les a aussi sans kernel (code de démarrage), et puis de toute façon, les F-Line ROM_CALLs sont la meilleure solution. * Les sections BSS, on les a aussi sans kernel (à l'aide du code de démarrage), elles aussi.

quelle est la taille de ce code ?

Flanker
:

* Les librairies dynamiques obligent l'utilisateur à faire une partie du boulot du programmeur (récupérer les dépendances et les mettre à jour toutes individuellement) et à gaspiller de la place sur sa calculatrice pour des fonctions inutilisées.

elles sont en général fournies avec le programme.

Et <SARCASM>vive</SARCASM> les anciennes DLL qui traînent, et qui en plus sont souvent incompatibles avec les programmes plus récents... Cf. aussi la DLL hell sous Windows...

Ben non, Iceberg ne remplace pas GhostBuster, tu es quand-même obligé de patcher tes programmes pour la Titanium.

pour tous les programmes ?

Pour presque tous. En kernel comme en _nostub.

* Les ROM_CALLs par relogement, on les a aussi sans kernel (code de démarrage), et puis de toute façon, les F-Line ROM_CALLs sont la meilleure solution. * Les sections BSS, on les a aussi sans kernel (à l'aide du code de démarrage), elles aussi.

quelle est la taille de ce code ?

Minime. La valeur précise dépend de plusieurs facteurs, notamment: des fonctionnalités utilisées (ROM_CALLs, BSS, variable de données externe), du type de relogements choisi (le code pour décompresser les relogements compressés prend plus de place, évidemment), du type de section BSS (initialisée à 0 ou pas initialisée du tout). Mais c'est de l'ordre de grandeur de 100 octets (ce qui n'est pratiquement rien sur un gros programme, et très petit par rapport à un kernel aussi).