AmigaOS 5 pour tout le monde ?
-
@Ball000 & Amidark:
Donc, quand on me fait passer pour un gros naze bourrin et inculte quand je parle de SMP sous AOS/Morphos et AROS, c’est qu’en gros, ce que je dis n’est pas forcément faux et qu’on est pas obligé de “tout péter” pour ajouter une once de SMP à nos OS préféré?
Donc je suis pas si Naze et inculte? (vous avez remarqué que j’ai gardé bourrin car malheureusement je le suis 🙁 désolé j’suis un sanguin)
Et dois-je rappeler que si l’OS ne dispose pas (encore ?) de la protection mémoire, il y en a pourtant des prémisses fonctionnels : ainsi le noyau et ce qui est considéré comme étant en ROM sont protégés par la MMU contre toute tentative d’écriture. Et bien sûr beaucoup d’autres exemples montrent qu’on est bien au delà des seules fonctionnalités d’AmigaOS 3.x.
Le Kickstart AmigaOS 3.x étant en ROM (donc protégé en écriture), il a la même fonctionnalité… Et sinon Enforcer ou ses clones (et éventuellement un GuardianAngel ou ses clones) pour protéger la première page mémoire etc… Même UAE intègre tout cela d’origine, c’est dire…
Bref rien de nouveau depuis les années 90′ et tous les OS actuels sont logés à la même enseigne.
@Artblink
Tu es “naze et inculte” : AROS n’ayant pas les même soucis de compatibilité ascendante à conserver, ils peuvent se permettre d’essayer ce genre de trucs. Au pire, ils peuvent modifier le source des applis incompatibles. Et puis c’est le tout début (quelques jours à peine), expérimental et ils on bien le temps de voir… : ) Même pas sûr que ça boot pour l’instant…
Bref rien de nouveau depuis les années 90? et tous les OS actuels sont logés à la même enseigne.
Moi si, je trouve qu’il y a eu beaucoup d’évolutions par ailleurs depuis les années 90. Mais tu disais peut-être cela juste pour la protection mémoire ?
À propos spécifiquement de la protection mémoire, Michal Schulz voulait aller beaucoup plus loin quand il implémentait x86-64-aros, mais certains développeurs n’étaient pas d’accord avec la petite perte de compatibilité nécessaire (au niveau source évidemment, et cela n’aurait été implémenté que sur cette version) et Michal les a écoutés (à regrets je crois). Staf Verhaegen pense qu’il est possible de protéger plus qu’actuellement sans perdre de compatibilité, et il compte s’y essayer (entre autres choses) quand il en aura fini avec la réorganisation en cours de l’ABI C.
Quant au SillySMP (“SMP stupide” !), le but est pour l’instant entre autres de voir si ça peut fonctionner sans perte de compatibilité (cf. le mél pointé dans mon précédent post). Donc on pourrait imaginer un UAE qui apporterait plusieurs cœurs 68k, et AROS répartirait entre eux les applications et les bibliothèques Amiga (l’idée en a été évoquée en tous cas). En termes techniques, il est clair qu’à ce stade ce sera loin d’être optimum, puisque pour l’instant les Disable() et les Forbid() bloqueront tous les cœurs… Mais on n’en est qu’au début, et c’est passionnant.
@henes: pour un programmeur qui m’a l’air super expérimenté, sa me fais mal au cul… Il y a plu d’optimiseur ou de bidouilleur sur nos OS?!
Bin va falloir que je retourne sur PCul 😉
La majorité parle d’un OS super balaise sans pognon pour le développer et je parle de bidouille simili SMP.
Bref, à une époque ou l’on disait que le miga en était incapable, 5 ans après il y arrivé et pas grâced à la bécane, mais au développeur…
Je pense qu’il est tjrs possible de bidouiller et je pense que ça reste la force de Amiga 😉
@ Artblink: ce que dit Henes va dans le sens de ce que tu disais plus haut , en gros, OUI le SMP est possible sur AROS car il n’y a rien a perdre en compatibilité binaire puisqu’elle n’a jamais existé 😉
Ce n’est malheureusement pas le cas pour MorphOS et l’AmigaOS4 qui tiennent à la compatibilité avec les vieux programmes comme à la prunelle de leurs yeux.
Le jour où on s’en foutra de perdre la compatibilité avec les anciennes Applis, alors ce sera aussi possible sur ces OS.Ce n’est pas une question de talents pour optimiser/bidouiller, c’est juste le cadre logique des choses.
C’est comme les lois de la physique, tu ne peux les enfreindre, par contre tu peux les contourner et cela avec les conséquence qui vont avec.En gros, pour voler, c’est bien plus intelligent de compter sur une aile Delta ou un avion que de faire confiance aux douces paroles d’un magicien 😉
/me n’est plus certain que ses analogies soient si parlantes 😀
RyZen Rulez 😉
J’aimerais éclaircir les choses un petit peu parce que j’ai l’impression qu’il y a un peu du … “je dit n’importe quoi”.
Source : http://aros.sourceforge.net/
Citation : the AROS Research Operating System is a lightweight, efficient, and flexible desktop operating system, designed to help you make the most of your computer. It’s an independent, portable and free project, aiming at being compatible with AmigaOS at the API level (like Wine, unlike UAE), while improving on it in many areas. The source code is available under an open source license, which allows anyone to freely improve upon it.Donc l’objectif principal de AROS (mentionné sur la page officielle) c’est d’être compatible AmigaOS au niveau API (c’est à dire les library, devices, datatypes, etc…)
Et ce en ayant un OS qui tourne sur des CPU différents des 68k … Genre x86, x64, PPC
Alors l’histoire du “Sur AROS on s’en fout de la compatibilité AmigaOS” … faudrait voire à arrêter de dire n’importe nawak !Si on regarde bien :
AmigaOS4 est un OS Compatible AmigaOS niveau API tout comme AROS et fonctionnant sur un CPU différent des 68k (soit du PPC)
– AmigaOS4 intégre un UAE dont l’objectif est d’être comme WinUAE sur PC permettant de faire fonctionner les vieux jeux et applis.
– AmigaOS4 possède un JIT intégré qui permet une certaine compatibilité avec les anciens AmigaOS au niveau API uniquement, en émulant un 68020. (un peu comme un UAE mais sans émulation des chipsets intégré des Amiga Classics)MorphOS est un OS Compatible AmigaOS niveau API tout comme AROS et fonctionnant sur des CPU différents des 68k (les Gx des MAC)
Je suis désolé mais que ce soit AROS, AmigaOS4 ou MorphOS dans les 3 cas on a exactement le même résultat (avec plus ou moins d’options)…
Un truc que je pige pas, comment la façon d’organiser la mémoire peut rendre des logiciels incompatible?
Il y a pas moyen de façon logiciel de faire des lectures selon un ordre définie sans “PETER” les OS?
Si une mémoire se comporte comme une table? Bin une table on l’a lit dans le sens que l’on veux.
J’pige pas en quoi l’endianness soit un problème, ou j’ai loupé un épisode 😀
J’ai aussi beaucoup de peine à visualiser le problème d’indianness. Si j’ai bien compris la chose (que l’on hésite pas à me corriger si ma théorie est fausse), c’est un peu la différence qu’il y a entre la manière d’écrire les chiffres en français (21, c’est à dire la dixaine en premier et l’unité ensuite) et en allemand (einundzwanzig, c’est à dire l’unité en premier et la dixaine ensuite). Je vois bien ou est le problème lors du portage, mais je ne vois pas pourquoi ce n’est pas possible à régler simplement en recompilant les sources pour le processeur cible. En effet, de ce que je sais, macosX était en big indian sur ppc et est maintenant en little indian sur x86. Et l’argument des moyens d’Apple ne tient pas, car c’est les developpeurs de logiciels qui ont du adapter leur anciens soft ppc sur x86. Hors, même des petits programmes indépendants ont été portés sans soucis.
Je ne saisis donc pas qu’est-ce qui empecherait de faire la même chose avec AmigaOS 4 ou Morphos.
@Artblink: biensûr, on peut la lire dans le sens que l’on veut… Mais si un programme (68k) s’attend à la lire dans un sens, et que tu te retrouves sur un processeur qui le fera dans l’autre, tu fais comment ? Tu patches le programme ? à la volée ? Tu patches tous les programmes à la volée, tu patches tous les accès mémoire, à la volée ?
C’est bien ça le problème…
Si l’OS avait été pensé pour gérer le problème, on aurait un readBE(), et ça réglerait le problème, mais ce n’est pas le cas.
Unix est un des premiers OS permettant le même code de fonctionner sur des processeurs d’endianess différents. Donc MacOSX n’avait pas ce problème, puisque l’OS gère l’ordre différent…
@Serge : Je t’invite à lire ce que j’ai marqué. Car là, tu as “mélangé” les propos. Je ne parle pas de compatibilité binaire mais au niveau de l’API … Ce n’est pas la même chose …
Pour la compatibilité binaire AmigaOS sur AROS, tu as Janus-UAE … Tout comme les autres OS ( MorphOS & AmigaOS4 ) la compatibilité binaire passe par un émulateur …@Artblink & Guibrush :
Si je me rappelle bien, l’endianess cause ce genre de soucis :
Contenu de la Mémoire : 00000000 : 04 05 70 48
Lecture des 2 premiers octets en 16 bits : 04 05
Avec l’Endianess : 05 04
Pour ma part, j’ai crée un wrapping de données qui inversent les valeurs selon les formats de données pour la lecture@ Amidark :
Oui, c’est comme cela que je l’avais compris. Mais si on parle de porter l’OS sur une archi x86, le programmeur devra de toute façons recompiler son soft pour cette nouvelle plateforme, exactement comme les programmeurs ont du le faire lors du passage d’osx ppc à osx x86. Hors, si le compilateur est bien foutu, il peu faire la translation automatiquement lors de la compilation, comme le fait xcode dans le cas d’osx. Le programmeur n’a même pas à se soucier de l’indianness il me semble ?
Bon, on peux très bien patché à la volé pour les Prg 6800×0 vu que les PPC sont largement plus puissant, il n’y aura pas forcément de ralentissement visible ni de charge CPU énorme. Par contre, même si on inverse les mots de 16bits à la lecture, on peut très bien réordonner tous ça. Une équation devrait résoudre le problème à la lecture vu que l’on peux piquer les 2 premiers mots de 16 bits, on peut donc aller chercher le troisième sans prendre les 2 premier.
Si il y a un ordre de lecture c’est qu’elle est basé sur une équation, le CPU ne “vie” pas, il suis une suite logique.
@Guibrush: J’pensai à la même chose 😉
- Vous devez être connecté pour répondre à ce sujet.
› Forums › AmigaOS, MorphOS et AROS › Général › AmigaOS 5 pour tout le monde ?