Forum de Ti-Gen.org, le site francophone des TI

Bienvenue Invité ! Se connecter Mes sujets	Administrer
Utilisateurs actifs : Aucun membre + 1 visiteur

Avant de poster sur le forum, il y a des régles de bases à respecter pour une bonne entente et un respect de tous.
Veuillez lire la charte du forum.

:: Index » Forum Ti68K » News » salut pour qd preos pour 2.09 (44 réponse(s))

./REPRISE DU POST PRECEDENT (post n°19) Marquer comme non lu.

Lionel Debroux

Ecrit le: Jeudi 26 février 2004 à 17:40

Envoyer un message privé à Lionel Debroux

Membre: Maître Ultime

Messages: 1721

Membre n°10

Inscrit le 31 janvier 2004

jackiechan: geogeo a raison.
Tu sais très bien pourquoi je tiens au format AMS native, quitte à prendre des dizaines d'octets au début de chaque programme. Il faut un paquet de programmes pour que le gaspillage de place qui en résulte dépasse celui d'un kernel (installeur + stdlib)... Et le kernel prend pas mal de place en RAM.

Lionel Debroux - membre de TICT.

./Post n°20 Marquer comme non lu.

Invité

Ecrit le: Lundi 19 avril 2004 à 11:04

dsl mais pour mon premier poste je joue le boulet mais je ne sais que me servir de ma calculette pour executer les programmes (et oui je l'avoue) donc c'est quoi stp lionel le format ams native???

./Post n°21 Marquer comme non lu.

Akimaru

Ecrit le: Lundi 19 avril 2004 à 11:14

Membre: Newbie

Messages: 1

Membre n°204

Inscrit le 19 avril 2004

C'est moi l'invité j'ai oublier de me logger

./Post n°22 Marquer comme non lu.

matth

Ecrit le: Lundi 19 avril 2004 à 11:20

Membre privilégié

Messages: 1329

Membre n°54

Inscrit le 16 février 2004

Alors l'ASM natif, c'est les commandes binaires du processeur. Je m'explique : le processeur tourne a base de 0 et de 1. Ehh ben l'ASMnatif dicte directement les 0 et les 1, tandis que autrement, les programme dicte les instruction à un kernel, qui les converti ensuite en commande processeur => perte de temps, mais plus simple ...

J'ai pas dit de connerie Lionel, paske je vient de me reveiller la ... #silly#

Ici un peu de pub pour bestofmicro, n'hésiter pas a double-cliquer, vous y trouverez du matériel informatique tres interressant

http://www.informatiquefrance.com/stop-faute.jpg

./Post n°23 Marquer comme non lu.

Folco

Ecrit le: Lundi 19 avril 2004 à 12:49

Administrateur

Groupe: Staff de Ti-Gen

Messages: 1286

Membre n°181

Inscrit le 05 avril 2004

Oups, j'ai la très nette impression que ce n'est pas ça du tout. #fume#

Preos reste un kernel, pas un interpréteur.
Quand à l'assembleur, ça reste de l'assembleur, donc éxécuté directement

<<< Kernel Extremist©®™ >>>
Pas la peine d'aller là plus d'une fois tous les six mois...

"Il faut apprendre pour savoir qu'il faut apprendre pour savoir."

./Post n°24 Marquer comme non lu.

geogeo

Ecrit le: Lundi 19 avril 2004 à 13:14

Fondateur

Groupe: Staff de Ti-Gen

Groupe: Orage Studio

Messages: 4257

Membre n°3

Inscrit le 29 janvier 2004

En effet s'est pas ça du tout.

Un kernel permet juste d'executer un programme en assembleur suivant des régles précises du Kernel, table d'allocations, librairies diverses... Alors que le nostub est natif et n'a pas besoin de programme supplémentaire pour executer de l'assembleur.

Par contre le nostub ne supporte pas les RAM_CALLS mais peuvent être remplacées par des fonctions situées dans les ROM_CALLS. Il n'est pas possible de réaliser des librairies ce qui est un gros défaut du nostub comparé au kernel, mais il existe toujours les DLL.

Il faut savoir que le format ROM_CALLS est différent en Kernel et en Nostub.
Il faut savoir aussi que les programmes en Kernel possède une en tête les identifiants.

Un grand avantage du Kernel s'est qu'il est capabale de plus ou moins intercepeter les plantages et revenir normalement à l'écran home, ce que ne fait pas le nostub.

Maintenant niveau programmation en ASM il y a des différences à connaître comme la sauvegarde et restauration de registres, mais le code sera toujours executé de la même façon par le processeur, ce qui change s'est le mode de lancement du programme.

Webmaster du site.
Programmeur sur TI68K. Arkanoid, Nebulus, GFA-Basic.

Plus d'informations sur GFA-Basic (un langage Basic pour TI68K).
http://www.tigen.org/gfabasic

./Post n°25 Marquer comme non lu.

Billy Charvet

Ecrit le: Lundi 19 avril 2004 à 13:16

Envoyer un message privé à Billy Charvet

Membre: Maître Ultime

Groupe: Storm Team

Messages: 1056

Membre n°61

Inscrit le 23 février 2004

Le NoStub, c'est les programmes pour lesquels tu n'as pas besoin
d'utiliser de kernel comme PreOS.

Le natif == le NoStub, à la base (avant que Kevin foute tous ces trucs dans
TIGCC comme le wrapper (et encore ça c'est gentil))

Je suis tel la fleur du lotus.
Bien que naissant de la boue,
aucune boue n'y adhère.

./Post n°26 Marquer comme non lu.

matth

Ecrit le: Lundi 19 avril 2004 à 13:21

Membre privilégié

Messages: 1329

Membre n°54

Inscrit le 16 février 2004

Bon, ben je retourne me coucher, ca m'apprendra a me lever aussi tot apres m'etre couché assi tard ... (forcément, y'avait independance day a la télé et puis apres j'ai continuer a référancer tt les progs de ticalc ... #mur#

Ici un peu de pub pour bestofmicro, n'hésiter pas a double-cliquer, vous y trouverez du matériel informatique tres interressant

./Post n°27 Marquer comme non lu.

mathiniste

Ecrit le: Lundi 19 avril 2004 à 14:20

Membre: Maître Ultime

Messages: 2057

Membre n°189

Inscrit le 12 avril 2004

cherche un peu!!!!surtout qu'elle déjà sortie!!!

la mort n'a aucun rapport avec nous.Quand nous sommes vivants, la mort n'est pas là et quand elle est là, nous ne sommes plus...

./Post n°28 Marquer comme non lu.

matth

Ecrit le: Lundi 19 avril 2004 à 14:31

Membre privilégié

Messages: 1329

Membre n°54

Inscrit le 16 février 2004

oué, mé moi je les ajout a tigen !! et ca c'est beaucoup plus long !

Ici un peu de pub pour bestofmicro, n'hésiter pas a double-cliquer, vous y trouverez du matériel informatique tres interressant

./Post n°29 Marquer comme non lu.

Lionel Debroux

Ecrit le: Lundi 19 avril 2004 à 18:47

Membre: Maître Ultime

Messages: 1721

Membre n°10

Inscrit le 31 janvier 2004

> Un kernel permet juste d'executer un programme en assembleur suivant des régles précises du Kernel, table d'allocations, librairies diverses...
> Alors que le nostub est natif et n'a pas besoin de programme supplémentaire pour executer de l'assembleur.
OK.

> Par contre le nostub ne supporte pas les RAM_CALLS mais peuvent être remplacées par des fonctions situées dans les ROM_CALLS.
Vrai. Mais ce qui remplace certains RAM_CALLs en AMS native est plus optimisé (d(pc) au lieu de xxx.l).
> Il n'est pas possible de réaliser des librairies ce qui est un gros défaut du nostub comparé au kernel, mais il existe toujours les DLL.
Gros défaut, c'est vite dit... Quand on voit ce à quoi servent certaines librairies (les libs de 100 octets juste pour sauver le jeu), on se demande.
Et il existe une interface de lib dynamique utilisable par les deux modes, c'est les frames des FlashApps. Mais ça ne marche pas sous les AMS anciens, toujours répandus, c'est pour ça qu'on ne l'utilise presque pas en ASM, dans quelque mode que ce soit.

> Il faut savoir que le format ROM_CALLS est différent en Kernel et en Nostub.
Hmm, faux depuis TIGCC 0.95, l'AMS native peut avoir des ROM_CALLs au format kernel.
> Il faut savoir aussi que les programmes en Kernel possède une en tête les identifiants.
Vrai, c'est ce qu'on appelle le stub.

> Un grand avantage du Kernel s'est qu'il est capabale de plus ou moins intercepeter les plantages et revenir normalement à l'écran home, ce que ne fait pas le nostub.
Faux, KerNO existe, et on peut très bien faire sa propre protection anti-crash (c'est ce que Patrick Davidson fait; Greg Dietsche a fait CrashLib).

> Maintenant niveau programmation en ASM il y a des différences à connaître comme la sauvegarde et restauration de registres, mais le code sera toujours executé de la même façon par le processeur, ce qui change s'est le mode de lancement du programme.
Oui. Les programmes kernel ne respectent d'ailleurs pas tous la convention d'appel d'AMS (registres qu'on peut détruire dans une fonction sans restaurer), ce qui les rend moins stables.
Regardez le fichier de PedroM contenant les programmes testés sous PedroM (qui contient d'ailleurs des versions dépassées - pratique pour avoir moins de rejets...): il y a deux programmes qui assument que d1 et d2 ont une valeur particulière, alors que la calling convention d'AMS est "can destroy d0-d2/a0-a1".

Certains programmes kernels (les plus vieux) ont un certain nombre d'aberrations dont sont exempts les programmes AMS native, plus récents. Un nombre non négligeable de programmes kernel-based ne tournent que sur HW1, pour les faire tourner sur HW2 il faut un port (ça vient aussi de la méthode pour faire le grayscale, mais pas seulement). Par exemple, l'utilisation d'adresses absolues pour accéder aux variables du système... C'est très fin, et AMS 2.00 a heureusement tout breaké: de tels usages sont mauvais.

Lionel Debroux - membre de TICT.

./Post n°30 Marquer comme non lu.

Kevin Kofler

Ecrit le: Lundi 19 avril 2004 à 23:32

Administrateur

Groupe: Staff de Ti-Gen

Messages: 4814

Membre n°40

Inscrit le 08 février 2004

Un grand avantage du Kernel s'est qu'il est capabale de plus ou moins intercepeter les plantages et revenir normalement à l'écran home, ce que ne fait pas le nostub.

PreOs peut aussi intercepter les plantages des programmes _nostub.

Le natif == le NoStub, à la base (avant que Kevin foute tous ces trucs dans
TIGCC comme le wrapper (et encore ça c'est gentil))

* C'est Sebastian qui a rajouté ça.
* Le code de démarrage est souvent pratique pour économiser de la taille.
* Le nouveau linker distingue _nostub strict et _tigcc_native.

Membre de l'équipe de TIGCC: http://tigcc.ticalc.org
Mainteneur du portage Linux/Unix de TIGCC: http://tigcc.ticalc.org/linux/
Membre de l'équipe de CalcForge: http://www.calcforge.org:70/

Participez à la reprise de Ti-Gen!

./Post n°31 Marquer comme non lu.

Invité

Ecrit le: Mardi 20 avril 2004 à 02:20

"Certains programmes kernels (les plus vieux) ont un certain nombre d'aberrations dont sont exempts les programmes AMS native, plus récents. Un nombre non négligeable de programmes kernel-based ne tournent que sur HW1, pour les faire tourner sur HW2 il faut un port (ça vient aussi de la méthode pour faire le grayscale, mais pas seulement). Par exemple, l'utilisation d'adresses absolues pour accéder aux variables du système... C'est très fin, et AMS 2.00 a heureusement tout breaké: de tels usages sont mauvais."

ça n'a rien à voir avec kernel / nostub
les vieux programmes sont plus buggués que les récents car ils étaient codés en asm et non en C et la connaissance de la ti était alors bien moins grande qu'actuellement.

./Post n°32 Marquer comme non lu.

Kevin Kofler

Ecrit le: Mardi 20 avril 2004 à 02:55

Administrateur

Groupe: Staff de Ti-Gen

Messages: 4814

Membre n°40

Inscrit le 08 février 2004

Non, parce que les développeurs TI-89/92+ ne se sont pas informés!

C'était écrit dans le tios.h de Fargo!

; Unless otherwise specified, assume that D0-D2/A0-A1 are destroyed by any
; given ROM function upon return.

Et c'est même écrit dans romlib.fn de Fargo 0.1.14, daté 1er novembre 1997:

; Unless otherwise specified, assume that D0-D2/A0-A1 are destroyed by any
; given function in ROMlib.

(Dans 0.1.12 et 0.1.13, il y avait écrit "D0-D1/A0-A1".) Bref, les premiers développeurs TI-89/92+ étaient des incultes!

./Post n°33 Marquer comme non lu.

Lionel Debroux

Ecrit le: Mardi 20 avril 2004 à 20:07

Membre: Maître Ultime

Messages: 1721

Membre n°10

Inscrit le 31 janvier 2004

> les vieux programmes sont plus buggués que les récents car ils étaient codés en asm et non en C et la connaissance de la ti était alors bien moins grande qu'actuellement.
Il est vrai qu'il est plus facile de faire du code buggé en ASM qu'en C, et qu'on connaissait très mal la TI quand les programmes ont été portés. Mais les développeurs auraient pu éviter un certain nombre d'aberrations. Celles qui me viennent à l'esprit maintenant sont:
* la Flash, ça sert à quoi ? A des updates par exemple. Et un update peut breaker des trucs, notamment les adresses absolues vers les variables du système, qui n'auraient jamais dû exister;
* faire du port plutôt que de la réécriture, passé un certain point. Ca n'a pas été fait pour beaucoup de programmes, mais le système de libs était instable(filelib au début !)...
* mauvaise calling convention.

Lionel Debroux - membre de TICT.

./Post n°34 Marquer comme non lu.

Invité

Ecrit le: Mardi 4 mai 2004 à 21:08

On peut faire un "patch" de la ROM ? Un programme assembleur qui modifie le système d'exploitation, pour ne plus perdre les modifications et pour garder les optimisations dûes par exemple à l'installation de PreOS.