AmigaOS 5 pour tout le monde ?
-
Bah! tu m’fais marché 😉
sérieux?
De toute façon on veux rester compatible avec les Amiga os 6800×0, mais on est pas obliger de faire l’inverse, un prg sous Amigaos 4.1.X ou Morphos ou Aros n’est pas obligé d’être compatible 6800×0.
Mais je suis pas assez calé la dedans…
C’est dommage que le C soit si compliqué pour moi, ça doit être vachement intéressant de bidouiller en C surtout lorsque l’on tape dans le système
@Leo : Sur ce point là, on est d’accord. Ma réponse était lié à l’argumentation de Serge.
@GuiBrush :
Le compileur fera la convertion pour la partie CODE binaire … mais concernant les fichiers de données … rien ne sera fait. Ce sera au développeur de mettre un petit correctif pour changer la façon dont les données ( 16, 32 (, 64) bits sont lues dans la mémoire).@Artblink :
Il vaut mieux reprendre tout à la source et modifier soi même toutes les données plutôt que de le faire à la volée pendant l’exécution du programme … Tu t’imagines devoir reprendre toutes les données graphiques pendant l’exécution du programme pour pouvoir les décompresser et les stoquer en mémoire … perte de temps …Pour la “rétro compatibilité” ArtBlink, tu as raison.
Sur AmigaOS4 :
– le JIT 68020 n’est là QUE pour assurer la compatibilité “processeur” avec les Amiga Classics …
– l’AmigaOS4 de part sa conception assure une compatibilité au niveau de l’API envers les Amiga Classics
– Rien dans l’AmigaOS4 n’est prévu pour la compatibilité des chipsets Amiga Classics … Cette compatibilité là, quelque soit l’OS passe par un UAE
– L’AmigaOS4 contient des fonctions dans l’API qui n’existent pas sous Amiga Classics, une application purement AmigaOS4 n’est pas compatible Amiga Classics.xcode ne “translate” rien du tout : il ne byteswap rien et ne gère aucun problème d’endianess. Le problème n’existe pas sur OSX (ou avec qemu qui permet de lancer un binaire Linux PPC sur Linux x86).
Sur les Unix, les structures systèmes ne sont pas apparentes. Les programmes manipulent des entiers. Par exemple le process numéro “7” va correspondre pour le noyau à une tache située à l’adresse “987654”. Et à cette adresse tout est natif dans l’endianess favorite du CPU et bien aligné sur le bon multiple pour aller super super vite. Mais les programmes ne connaissent que le 7 et ne voient jamais le 987654.
Au pire si du code applicatif bigendian aurait besoin de donner ce “7” bigendian au noyau little endian pour qu’il en fasse quelque chose… ce code bigendian passerait sans le savoir par un petit stub/wrapper/bout_de_code_dédié_du_système qui transformerait ce 7 bigendian en 7 littleendian et ensuite tout fonctionnerait en little endian dans le noyau.
Tout le système peut donc être littleendian. Il ne sait même pas qu’il y a du n’importe quoi bigendian qui essaye de tourner quelque part.
L’ensemble du système peut donc être natif, optimisé à mort etc tout ce que tu veux.
Cela n’a strictement absolument et définitivement vraiment rien à voir avec comment un Amiga est obligé de fonctionner jusqu’à la fin des temps s’il veut être compatible avec lui même.
Sur Amiga, pas de “7”. Le système est ainsi fait qu’on manipule directement l’adresse “987654” et tout ce qu’il y a derrière elle. A l’adresse 987654, il y a peut-être une autre adresse 456789. Et à l’adresse 456789, il y a peut-être une autre adresse 654321 etc…
Le 68k bigendian étant arrivé en premier sur Amiga, cela veut dire que les logiciels doivent écrire ce 987654 en bigendian. Et le 456789 en bigendian aussi. Et le 654321 en bigendian etc…
Les données de la tache 987654 doivent donc être stockées en bigendian. Le système pourtant littleendian va donc devoir absolument les manipuler en bigendian. Et de fil en aiguille il en est de même pour les données à l’adresse 456789. Et à l’adresse 654321 etc.
Bref au final quasi tout doit être bigendian et respecter les contraintes d’alignement du 68k qui ne sont pas forcément optimales pour un x86 (c’est à dire que le CPU rame pour accéder aux données). Alors que le CPU est littleendian.
Au final, oui il serait théoriquement possible de faire un AmigaOS x86 similaire à MorphOS et HyperOS : qui exécute des programmes natifs x86 et des programmes 68k de manière transparentes.
MAIS toutes les structures systèmes publiques devraient être bigendian et alignées sur 16 bit. Ces structures systèmes étant, sur Amiga, les structures internes de l’OS : la majorité/beaucoup des données internes au systèmes devraient être bigendian et alignées sur 16bit.
Et, sur Amiga, ces données “internes” au système étant créées et manipulées par les programmes applicatifs… les programmes natifs x86 littleendian devraient donc manipuler toutes les structures systèmes en bigendian aussi.
Bref, grosso-modo, mis à part les données privées des applis x86, tout devrait être bigendian et aligné sur 16bit comme sur 68k.
Les logiciels AmigaOS x86 devraient donc tous faire des transformations little<->big endian pour chaque truc système. Et aller lire ces trucs via du code spécialement prévu pour ne pas planter ou ramer lorsqu’une donnée n’est pas alignée comme il faut.
Et il en est de même pour l’OS lui même. Du noyau jusqu’à la dernière bibliothèque perdue au fin fond du disque dur.
Techniquement c’est réalisable. Mais personne ne veut faire un OS et des applis ainsi compliquées et qui, à machine égale, seraient plus lentes que l’ensemble des autres OS : Windows, OSX etc…
Cela n’aurait juste aucun sens. A part pour le fun de dire “on l’a fait”…
@Henes :
MAIS toutes les structures systèmes publiques devraient être bigendian et alignées sur 16 bit. Ces structures systèmes étant, sur Amiga, les structures internes de l’OS : la majorité/beaucoup des données internes au systèmes devraient être bigendian et alignées sur 16bit.
Ne serait-il pas possible d’avoir simplement 2 versions des données systèmes en mémoire ? Sachant qu’elles sont accessibles uniquement pour de la “lecture” … Ca boufferait un peu plus de mémoire mais ça éviterai à l’utilisateur d’avoir à faire les changements sans arrêt… non ?
Cependant, une question que je me pose … C’est pas un peu les x86 qui sont venus foutre la merde dans l’histoire ?
Je trouve plus “logique” et “normal” que lorsque j’ai une suite de 4 octets genre : 04 82 5f 7e
Si je les lits en 32 bits j’ai bien 04 82 5f 7e et non pas des données mélangées car il lit pas à l’endroit …
Donc Motorola aurait fait un truc normal qui est mort … mais les autres ont fait un système chiant qui tient le coup … Enfin bref …Ce serait compliqué, il faudrait garder tout cela synchronisé de manière atomique (donc en coupant le multitache) et impacterait tout l’OS et les programmes natifs x86 pour rien…
Et de toute façon elles ne sont pas en lecture seule.
struct Message, Node, Task, Process etc etc etc…. tout cela peut et doit être modifié par les programmes applicatifs. Nombre de structures commencent d’ailleurs directement ou indirectemment par un struct Node…
Sans parler des structures allouées (parfois sur la pile, c’est légal) et initialisées à la main par des programmes avant d’être insérées dans le reste du système comme il se doit.
Et on retombe sur nos pattes. C’est exactement ce qu’est AROS en ce moment.
@Amidark: Intel a inventé le processeur, donc c’est bien Motorola qui est venu foutre la zone même si pour tous le fonctionnement des processeurs Mororola nous semble plus intuitif du point de vue Endianess.Avec ce qui est expliqué plus haut, il est facile de comprendre que AROS est différent d’AmigaOS4 et MorphOS et qu’il ne suffit pas de lui ajouter un émulateur 68k comme sur ses frères pour qu’il exécute des Applis 68k. C’est tout le système qu’il faudrait alourdir de traducteurs dans tous les sens.
Résultat des cours, l’affirmation qui dit qu’on n’a rien a perdre en cassant la compatibilité elle est vrai puisque la compatibilité binaire n’a jamais existé et la compatibilite sources n’a d’intérêt que pour partager facilement des développements entre tous les systèmes Amiga-Like.
Personnellement, je suis totalement pour l’implémentation de fonctions évoluées ( SMP, protection memoire etc ) dans AROS. Ça l’éloignerait des autres Amiga-Like en compatibilite mais ça l’enrichirait.
AmigaOS4 et MorphOS ont bien plus à perdre ( en apparences ) ce qui rebute ce passage brutal, néanmoins je pense qu’on devrait aussi y passer et implémenter un UAE dans les 3 systèmes pour la compatibilité.
RyZen Rulez 😉
@Henes : Oui je comprends, j’avais oublié tous ces détails :p
Dans ce cas là, la solution serait de « virtualiser » ? Exécuter une application dans une « box » comme on pourrait dire. non ?Oui. C’est ce qu’à fait MorphOS dès son lancement. Et ce que n’a pas choisi de faire OS4… Ce dernier est donc obligé de tout repéter pour passer sur un processeur avec un autre endianess.
Sinon, il ne faut pas oublier que le z80, le 6502,… sont aussi little-endian. Et le PowerPC (enfin, sauf le G5/975) et bien d’autres (Sparc,…) sont bi-endian.
Mais le problème c’est surtout que l’OS n’abstrait pas cette notion et donne accès à tous à tous les programmes: on en revient toujours au même problème. C’est source de problème pour l’endianess, mais aussi pour le SMP, …
En fait le VRAI probleme : c est que vous voudriez etre sur x86
mais continuer a lancer vos vieux progs 68k d il y a 20 ans
Auxquel cas on tombe bien dans le cas le pire : celui ou une simple jit pour 68k
veut quand meme acceder a l api qui a une endianess differentesinon si vous utilisez un uae (comme winuae) et rien que des applis x86 faites pour cet
amigaos x86 alors pas de probleme
Car dans ce cas l endianess ne pose que 2 problemes:
lire des fichiers avec donnees binaires dans un autre ordre
envoyer des donnees vers une chip (video) avec le bon orderingAlain
En effet Alain, là est tout le problème de l’endianes qui n’existe pas sur AROS puisqu’il ne cherche pas a exécuter des programmes 68k.
Mais même si ces nouvelles pour AROS sont super bonnes, ça ne fait pas de lui l’AmigaOS5 tel que le définit Elwood en premier POST 🙂
En effet, même avec le SMP, la protection mémoire et le résout e tracking, tout cela ne rendra pas AROS plus apte a utiliser les drivers déjà existants dans le monde UNIX.
RyZen Rulez 😉
@Henes :
Ok, merci pour cette explication très détaillée, j’y vois plus claire maintenant. En gros, si j’ai bien compris, ce qui pose problème avec AmigaOS et Morphos, c’est qu’il n’y a pas de HAL au niveau des fonction du systèmes et que chaque programme attaque directement la fonction, chose qu’il n’y a pas sur osX ? En tout les cas, si on prend tout ça en compte, il semble que le choix d’évolution du matériel pour les AmigaOS NG est bien limité….. Sauf pour Aros !
Maintenant, une autre question : comment diable faisait Amithlon pour permette des softs 68k et x86 de s’éxecuter conjointement dans le système ? En effet, il était possible de coder une application en x86 sous Amithlon. Pourtant, le problème de l’Indianness devait aussi se présenter ?
Je ne connais pas assez Amithlon pour en parler…
Mais il fait tourner un OS 68k donc les programmes “natifs x86” prévu pour Amithlon font forcément des conversions little<->big (byteswap)…
Et Martin Blom (AHI) avait d’ailleurs travaillé sur un GCC hacké pour générer du code qui byteswap tout ce qu’il touche…
Cela dit, j’ai toujours compris que l’auteur d’Amithlon n’avait pas pour but de faire un OS au top qui puisse rivaliser en performance avec ce qui se fait de mieux…. mais de faire l’Amiga 68k le plus rapide.
Donc tout ce que j’ai décrit plus haut comme étant horrible et inefficace de mon point de vue… n’a pas forcément de sens dans le context d’Amithlon (qui se fiche que ce ne soit pas optimum tant que c’est largement plus rapide que les autres Amiga).
- Vous devez être connecté pour répondre à ce sujet.
› Forums › AmigaOS, MorphOS et AROS › Général › AmigaOS 5 pour tout le monde ?