Kernel ou _nostub ? - Page 4

Je ne connais absolument pas le format kernel v6
Quels avantages peut-il avoir par rapport à -freg-relative-an et/ou une architecture shared memory pour les communications entre différents bouts de programmes chargeables et déchargeables dynamiquement comme je l'ai fait dans le topic sur Dune 2 ?

Ouai vive le Nokerstubnel ^^

Au fait, vous saviez que Kevin avait un caractère à lui tout seul ? Le ㏍ (U+33CD SQUARE KK)

92: pour ceux qui ont pas cette police merveilleuse: http://www.unipad.org/unimap/index.php?page=detail&param_char=33CD

Kevin Nel !!!

Folco, tu rèves, c'est le _nostub qui gagne.

Avec quels arguments en réponse à ceux de Martial ?

Que les fonctionnalités qu'il décrit ne servent strictement à rien en pratique, que couper un programme en morceaux de cette manière crée un énorme overhead et que c'est le bordel pour l'utilisateur qui se retrouve avec plein de fichiers quand 1 ou 2 (lanceur+PPG) suffi(sen)t (et j'ai déjà dit tout ça dans les topics où il a présenté cette technologie ridicule) et que le kernel a plein d'inconvénients qui ont été déjà discutés dans les nombreux topics précédents à ce sujet, par exemple la complexité d'installation pour l'utilisateur.

A priori martial ne fait qu'une seul fichier

Même s'il faut toujours se méfier quand Kevin dit que quelque chose "ne sert strictement à rien" (ce qu'il dit souvent ), là, je pense qu'il a plutôt raison...

Ce n'est pas parce que PreOS intègre déjà des APIs qui permettent de faire une jolie prouesse technique (d'après ce que tu dis), que c'est intéressant (en taille et en vitesse) de les utiliser.
En particulier, ton cas d'utilisation (petit programme avec des parties peu dépendantes les unes des autres, tournant dans moins de RAM) ne me paraît pas très intéressant _en pratique_ _sur les TI-68k_: non seulement on n'a pas des contraintes de RAM à ce point-là, mais de plus, le chiffre d'utilisation de RAM que tu donnes est trop faible pour inclure la consommation du kernel lui-même
Faire une tech demo comme ça sur de gros programmes qui ont certaines parties peu dépendantes du reste (ce qui est potentiellement le cas du Dune 2 de CBsoft) serait à mon sens plus pertinent. Mais il restera la consommation du kernel lui-même et la contrainte d'avoir un kernel.

Lionel Debroux (./102) :
Faire une tech demo comme ça sur de gros programmes qui ont certaines parties peu dépendantes du reste (ce qui est potentiellement le cas du Dune 2 de CBsoft) serait à mon sens plus pertinent. Mais il restera la consommation du kernel lui-même et la contrainte d'avoir un kernel.

Ben disons que je pense que si le kernel facilite tout ça, et qu'on peut faire que ça marche tres bien avec un minimum de mémoire, c'est pas forcement mal de faire un bankswitching "soft"

C'est certain que pour un programme qui console 16K de code au final, ça n'a aucun sens, mais imaginont une appli qui en ferais 127 ? ou plus ? ou alors qui consome enormement de mémoire pour ces variables internes, et non pour le code ? (genre on a 256Ko de ram, on a 200+Ko de mémoire utilisé pour les variables, et le soft fait presque 60Ko de code, il faut bien faire quelque chose...

C'est un cas extreme je sais mais c'est dans l'idée ^^

Faudrait voir la vitesse du bankswitching soft... Je vois mal comment il serait plus rapide qu'un chargement en AMS natif équivalent.

(ce qui est cool c'est que ça a commencé par rigoler mais le troll est sincèrement reparti )

Tu t'attendais à quoi ?

à ce que kernel powaaaaaaa !

Kevin Kofler (./100) :
Que les fonctionnalités qu'il décrit ne servent strictement à rien en pratique

Si : gagner plein de mémoire vive.

que couper un programme en morceaux de cette manière crée un énorme overhead

L'overhead introduit par le nostub est bien plus énorme.

C'est le bordel pour l'utilisateur qui se retrouve avec plein de fichiers quand 1 ou 2 (lanceur+PPG) suffi(sen)t

Il n'y a qu'un fichier.


Bref : kernel is the best

non, ça sux parce que le nostub a la plus grosse

(LD: exactement à ça en fait )

Thibaut fin comme du gros sel, comme d'habitude...

Lionel Debroux (./110) :
Thibaut fin comme du gros sel, comme d'habitude...

Et qui pègue bien en plus

(je sais pas si beaucoup savent ce que veut dire péguer )

Peux-tu développer Lionel ?

Manfoo

Thibaut (./108) :
plein

Thibaut (./108) :
plus énorme

Thibaut (./108) :
Bref : kernel is the best

Je crois qu'il parlait de ça ^^

./113: expand((1+x)^2,x)

Ah oui en effet c'est mon habitude. Mais personne n'est parfait, surtout pas le nostub

u are wrong on teh intarweb