Kernel vs Nostub? - Page 1

Moi je dit kernel rulez!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

moi je dis kernel et nostub suxxxxxxxxxxxxx !!!!!

non nostub sux.. c'est un truc de **

ba c ce que g dit

non kernel c'est un bon truc.. par rapport au nostub:!

moi je dit PoWuB PoWa !!!!!!!!

nostub c mieux ... pas besoin de reinstaller un kernel apres un reset

et l'anticrash il sert a quoi? si il suffit pas c'est que ton prog c'est de la dob

bah si tu veux reseter toi meme ...


pis d'abbord ca fait - de fichiers a envoyer au depart .... :]

moai.. mais a l'arrivé t'as 60KO de perdu car ca utilise pas de 'dll'

m'en fous de tte facon j'utilise plus ma TI

moi non plus

alors ca sert a rien de continuer le debat

De ttes façons, on sait ce qu'il faut faire pour contenter tt le monde : faire une version _nostub et une version kernel... Sinon ya toujours Kk ou un autre pour nous faire la tronche

non.. faire une version nostub est ridicule!!

yAro a écrit :
nostub c mieux ... pas besoin de reinstaller un kernel apres un reset

TiMad
a écrit : et l'anticrash il sert a quoi?

À rien. Il laisse la calculatrice dans un état instable, et puis je ne vois pas le problème de faire un reset avec une version récente de AMS: la récupération de l'archive fait en sorte que tu ne perds pas tes fichiers de toute façon.

Et puis si tu en veux absolument un: KerNO et PreOs contiennent des anticrashs pour programmes _nostub.

TiMad a écrit :
moai.. mais a l'arrivé t'as 60KO de perdu car ca utilise pas de 'dll'

Tu m'expliqueras comment tu trouves tes 60 KO, parce que je ne vois pas du tout d'où ils viennent. Tu dois avoir oublié dans tes calculs:
- la taille des DLLs
- la taille du kernel
Et même avec ça, je ne vois pas.

Une librairie dynamique est une perte de place, pas un gain de place, par rapport à une librairie statique. Ceux qui prétendent que c'est un gain oublient que la taille des librairies fait partie de la taille du programme, qu'elles soient statiques ou dynamiques.

TiMad
a écrit : non.. faire une version nostub est ridicule!!

Arrête de changer d'avis tous les 6 mois et d'insulter tout le monde qui ne partage pas ton avis de la saison. Il y a quelques mois, tu disais exactement le contraire. C'est quoi qui t'a fait changer d'avis?

héhé

imaginons.. cf sma pokred kirby sur une caltos , ces 4 programmes utilises Genlib => 4* la taille de genlib
meme remarque pour les prog utilisant graphlib

ma foi, qd à moi, je me prend pas la tête : kernel installé en permanence.
ainsi, anticrash en permanence, et qd j'envoie un prog sur ma calc (ou sur VTi), il fonctionne toujours, qu'il soit en mode nostub ou en mode kernel

heu ct 3*

D'accord avec squale92, perso je suis pro nostub, mais bon j'ai toujours un kernel soit installé, soit prêt à l'etre en m"moire et puis avec le dernier PreOS c'est pas très gormand en mémoire

hé, j'ai pas dit que gt pro quoi que ce soit !!!

perso, nostub ou kernel, je m'en fou un peu, tant que le prog est bien codé et bug pas (un prog qui plante pas en nostub plantera pas en kernel...)

qd je code en C, l'un ou l'autre, en général, je m'en fou
qd je code en ASM, par contre... je suis bien content d'avoir le kernel avec ses libs qui m'évitent de devoir poser 150 lignes de code pr une ou deux fonctions alors que ce je veux faire tient en 10 lignes
et qd je code ON calc (en ASM... en C, ma foi, il n'existe pas d'outil qui me permette de gérer des projets de taille interessante), je suis bien content d'avoir le kernel qui rattrape toutes mes conneries

En fait quand je dis que je suis d'accord avec c'est pour cette phrase;
>je me prend pas la tête : kernel installé en permanence.
ainsi, anticrash en permanence, et qd j'envoie un prog sur ma calc (ou sur VTi), il fonctionne toujours, qu'il soit en mode nostub ou en mode kernel

TiMad a écrit :
imaginons.. cf sma pokred kirby sur une caltos , ces 4 programmes utilises Genlib => 4* la taille de genlib

Faux. La différence est au maximum:
3 * la taille de genlib - la taille du kernel

Et en pratique, elle sera plus petite que ça parce que:
- tu ne tiens pas compte de la compression. Certes, genlib peut maintenant être compressée, mais les librairies statiques sont pratiquement toujours compressées (avec le programme). Donc la taille de la librairie est multipliée par 2/3 environ (le facteur de compression moyen de ttpack dans mes tests). On est donc à:
2 * la taille de genlib - la taille du kernel
de différence.
- ces programmes n'utilisent pas toutes les fonctions de genlib. Avec une librairie statique, seules les fonctions réellement utilisées se retrouveront sur la calculatrice.
- genlib n'est pas du tout optimisée en taille, parce que PpHd dit que "de toute façon il n'y a qu'une copie, donc on se fiche de la mémoire gaspillée" (ce qui est un raisonnement assez stupide à mon avis: même une copie de gaspillage de mémoire est du gaspillage de mémoire). Une librairie statique gaspillera nettement moins de place.
On est donc très loin de tes 60 KO de différence.

meme remarque pour les prog utilisant graphlib

C'est débile d'utiliser graphlib. Plus de la moitié de ses fonctions ne sont que des wrappers autour de ROM_CALLs ou des réimplémentations de ROM_CALLs. Et ce qui reste, c'est une implémentation médiocre des niveaux de gris. Il n'y a pas de double-buffering automatique (il y a une tentative de rajouter un support pour du double-buffering de manière sale, en permettant au programme de changer les adresses des plans, de la part de PpHd, mais seulement dans PreOs, et puis ce n'est pas du double-buffering automatique), pas de synchronisation, ... Et ma remarque s'applique encore: puisque c'est une librairie dynamique, ces fonctions totalement inutiles (qui ne font que réécrire des ROM_CALLs) traîneront sur la calculatrice alors qu'elles sont déjà dans la ROM. Ce n'est pas seulement de la duplication d'efforts, mais aussi un gaspillage de mémoire absurde.

TiMad
a écrit : heu ct 3*

LOL, tu t'en es rendu compte au moins.
N'oublie pas de soustraire la taille du kernel.

squale92
a écrit : (un prog qui plante pas en nostub plantera pas en kernel...)

Sauf s'il y a un bogue dans le kernel...
En codant en _nostub, on élimine une source d'incertitude pouvant causer des bogues.

qd je code en C, l'un ou l'autre, en général, je m'en fou
qd je code en ASM, par contre... je suis bien content d'avoir le kernel avec ses libs qui m'évitent de devoir poser 150 lignes de code pr une ou deux fonctions alors que ce je veux faire tient en 10 lignes

Tu connais tigcc.a? Il y a même une conversion pour CC qui est certainement utilisable avec AS d'une manière ou d'une autre.

squale92 a écrit :
et qd je code ON calc (en ASM... en C, ma foi, il n'existe pas d'outil qui me permette de gérer des projets de taille interessante), je suis bien content d'avoir le kernel qui rattrape toutes mes conneries

Tu connais KerNO?
Mais bon, l'anticrash _nostub de PreOs marche très bien. (Normal, ce sont ExtendeD et moi qui avons codé la moitié. PpHd n'était pas très motivé là-dessus. Moi si. )

C'est dingue comme un sujet si souvent abordé peut encore faire couler de l'encre (euuh, des pixels)

Kevin Kofler a écrit :
> et l'anticrash il sert a quoi? À rien. Il laisse la calculatrice dans un état instable

C'est clair. Moi, de toute façon après un "Crash Intercepted", je reset toujours la TI (après avoir archivé les quelques trucs que je veux garder et qui ne l'étaient pas déjà)

Et puis si tu en veux absolument un: KerNO et PreOs contiennent des anticrashs pour programmes _nostub.

Je n'ai toujours pas compris l'utilité de ce programme : à part ne pas permettre de lancer des prog kernels, il y a quoi d'autre qu'il ne permet pas ?

Une librairie dynamique est une perte de place, pas un gain de place, par rapport à une librairie statique.

Tu exagères avec cet argument : tu sais très bien que les deux perdent de la place : les dynamiques parce qu'on stocke des fonctions qu'on n'utilise pas forcément et les statiques, parce qu'on stocke plusieurs fois les même fonctions.

squale92 a écrit :
ma foi, qd à moi, je me prend pas la tête : kernel installé en permanence. ainsi, anticrash en permanence, et qd j'envoie un prog sur ma calc (ou sur VTi), il fonctionne toujours, qu'il soit en mode nostub ou en mode kernel

Pareil.

et qd je code ON calc (en ASM... en C, ma foi
, il n'existe pas d'outil qui me permette de gérer des projets de taille interessante), je suis bien content d'avoir le kernel qui rattrape toutes mes conneries

Oui, moi aussi. Même si en général, après un Crash Intercepted, je fais un reset.

Kevin Kofler a écrit :
- ces programmes n'utilisent pas toutes les fonctions de genlib. Avec une librairie statique, seules les fonctions réellement utilisées se retrouveront sur la calculatrice.

C'est débile d'utiliser graphlib

Complètement d'accord. graphlib est vraiment complètement dépassé et inutile.

jackiechan a écrit :
>Et puis si tu en veux absolument un: KerNO et PreOs contiennent des anticrashs pour programmes _nostub. Je n'ai toujours pas compris l'utilité de ce programme : à part ne pas permettre de lancer des prog kernels, il y a quoi d'autre qu'il ne permet pas ?

Ben, les plantages.
Il intercepte aussi "ASAP or Exec string too long" et "Invalid Program Reference". Et il contient un émulateur de Line 1111 pour AMS <= 2.03.

Ben, vu qu'il y en a qui ont l'air de n'avoir toujours pas compris, j'ai répété ma phrase classique en la mettant en gras cette fois-ci. Je sens que la prochaîne fois, ça risque d'être en gras, rouge et all-caps.

Kevin Kofler a écrit :
>Je n'ai toujours pas compris l'utilité de ce programme : à part ne pas permettre de lancer des prog kernels, il y a quoi d'autre qu'il ne permet pas ?
Ben, les plantages.
Il intercepte aussi "ASAP or Exec string too long" et "Invalid Program Reference". Et il contient un émulateur de Line 1111 pour AMS <= 2.03.

Mouais, pour moi KerNO restera un sous-kernel qui ne remplis pas toutes les fonctionnalités d'un kernel. Je ne vois vraiment pas l'intérêt d'utiliser un KerNO à la place d'un kernel.
Enfin, j'avoue que je ne sais pas exactement ce qu'il fait, ni ce qu'il ne fait pas. Donc peut-être qu'il a des trucs que PreOS ne fait pas. Mais dans le cas contraire, je ne vois vraiment pas pourquoi ce programme existe (et ne réponds pas : "pour gagner 5 ko")

Ben, vu qu'il y en a qui ont l'air de n'avoir toujours pas compris, j'ai répété ma phrase classique en la mettant en gras cette fois-ci. Je sens que la prochaîne fois, ça risque d'être en gras, rouge et all-caps.

Ben oui, mais cet argument n'est pas valable (comme je l'ai dit dans mon post #26) alors que tu t'efforces de le répéter...

KerNO existe:
- parce qu'à l'époque où il a été commencé, les kernels ne faisaient pas ce qu'il fait (anticrash pour programmes _nostub etc.).
- parce qu'il prend moins de place qu'un kernel.

jackiechan
a écrit : Ben oui, mais cet argument n'est pas valable (comme je l'ai dit dans mon post #26) alors que tu t'efforces de le répéter...

Il est viable, parce qu'il faut en tenir compte en faisant le calcul que TiMad nous a pondu! Il a compté comme si la librairie statique était copiée en entier dans les programmes!