Journal RiscOS et les systèmes inventifs des années 80

Posté par  . Licence CC By‑SA.
Étiquettes :
19
10
oct.
2020

Lu ce matin, un article passionnant nous raconte l'histoire de RiscOS (le système d'Acorn Computers) depuis les années 80 en s'intéressant aux possibilités de l'adapter au potentiel du matériel actuel.
Ces systèmes des années 80 (ceux d'Acorn, Commodore, Atari, Apple, Microsoft — et d'autres) ont leurs avantages et défauts en partage : ils sont rapides mais plantogènes. Pour faciliter leur conception et privilégier la vitesse, ces OS utilisaient le multi-tâche coopératif avec ses défaut de gestion de mémoire et étaient très proche du matériel, avec beaucoup d'assembleur. Je résume et simplifie bien entendu.
Quand les microprocesseurs ont évolué, apportant la protection mémoire, le multi-threading, le multi-processeur, et la possibilité du multi-tâche préemptif (et sa lenteur), aucun de ces systèmes n'a pu en tirer parti. Ils traitaient le proco comme un CPU de la génération d'avant qui va un peu plus vite. Sans parler du binaire ! quand des puces 16 bits, 32 bits, 64 bits sont apparus, ils continuaient de les utiliser en 8, 16 ou 32 bits (26 bits pour RiscOS), sans possibilité d'évolution.
Aucun de ces concepteur à part Microsoft n'a fait les changements nécessaires : tout reprendre à zéro en ajoutant des couches de compatibilité pour continuer de lancer les programmes d'avant. De fait, on peut toujours lancer des vieux programmes DOS ou Windows sur Windows 10, bien que le système n'ait plus rien à voir (de là, le côté « bouffi » du système de Microsoft). À la fin des années 90, Apple n'avait donc guère le choix en adoptant NextStep pour base de MacOSX : macOS ne pouvait pas évoluer. Je le répète, c'est un résumé grossier.
Cette compatibilé binaire est un fameux dilemme d'ailleurs. Plutôt que trop grossir, MacOSX l'évacue régulièrement. Linux choisit la compatibilité du code source recompilable sur plein d'architectures, mais va donc lancer un programme propriétaire pour Linux 2.6 sur un noyau actuel ! les distros ne sont pas adaptées. Déjà pour le 32 bits elles ont fait un effort, mais c'est parce que les processeurs sont compatibles — jusqu'à quand ? c'est toujours du résumé, pas taper merci.

Conclusion, je n'ai pas résumé l'histoire d'Acorn ni celles des puces ARM (d'Acorn aussi) pour vous laisser le plaisir de la lire dans cet article écrit en anglais simple, lisible, accessible. Comme RiscOS.

  • # Amiga

    Posté par  . Évalué à 10. Dernière modification le 10/10/20 à 22:30.

    AmigaOS était en multitâche préemptif dès le début.

    https://fr.wikipedia.org/wiki/Multitâche_préemptif

    Aussi on avait un patch qui priorisait mieux l'application en 1er plan pour avoir un peu plus de souplesse d'utilisation, mais les taches d'arrière-plan étaient fortement ralenties du coup.

    Le matos était excellent, en virtualisation de macOS ça tournait mieux que sur de l’Apple à CPU équivalent ;)

    • [^] # Re: Amiga

      Posté par  . Évalué à 5.

      Un système très en avance pour l'époque <3

  • # ABI Linux <> userspace

    Posté par  (site Web personnel) . Évalué à 10. Dernière modification le 10/10/20 à 23:23.

    Linux choisit la compatibilité du code source recompilable sur plein d'architectures, mais va donc lancer un programme propriétaire pour Linux 2.6 sur un noyau actuel !
    

    C'est tout simplement faux, ça n'est pas un problème de noyau. Le noyau Linux a pour politique de ne pas casser l'ABI avec les binaires. Le problème du vieux programme propriétaire, ça va être le reste de l'espace utilisateur et notamment la libc, les libs graphiques, etc… Mais un binaire propriétaire compilé en statique qui fonctionnait sur un noyau 2.6 doit continuer à fonctionner sur un noyau récent. Sinon, c'est un bug du noyau et il doit être corrigé.

    D'ailleurs, l'article d'origine ne parle de pas de problème avec le noyau.

    • [^] # Re: ABI Linux <> userspace

      Posté par  . Évalué à 7.

      La libc aussi garde une compatibilité ABI, c'est plutôt du côté des autres bibliothèques que la compatibilité est cassée.

      « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

    • [^] # Re: ABI Linux <> userspace

      Posté par  . Évalué à 5.

      D'ailleurs, l'article d'origine ne parle de pas de problème avec le noyau.

      Tiens une bonne idée : résumer en ajoutant des trucs faux pour faire lire l'article :-)
      J'avais mal compris, merci de la précision.

  • # résumé

    Posté par  . Évalué à 3.

    Joli teasing et donc je m'en vais de ce pas lire l'article que tu conseilles

  • # dis lemme !

    Posté par  (site Web personnel) . Évalué à 3.

    Même si c'est une erreur fréquente, c'est bien dilemme, oui le terme lemme comme en maths ;-)

    Bon, il y a un RicOS qui traîne aussi au passage avec un S perdu et une compatibilité ayant perdu son lien avec l'IT.

    Si tu as d'autres articles revenant sur les années 90 (Archimedes, NextSTEP… RISC vs CISC…), n'hésite pas _o/ (moui, j'étais un lecteur assidu de Jerry Pournelle dans Byte, et avec son pote Larry Niven aussi d'ailleurs :D OS/2 avec toutes ses qualités ne s'est que peu retrouvé dans NT4.1 qui était à la limite de l'utilisable, W2K en reprenant quelques bons éléments que ME et XP ont fait oublier à beaucoup de monde dans le grand public… même 8.1 n'a pas atteint le niveau catastrophique envisageable, autant attendre win11 s'il existe un jour).

    • [^] # Re: dis lemme !

      Posté par  . Évalué à 3.

      c'est bien dilemme

      corrigé

      il y a un RicOS qui traîne

      corrigé

      ainsi qu'un Atari qui a pris un T de trop.

      En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

    • [^] # Re: dis lemme !

      Posté par  (site Web personnel) . Évalué à 3.

      Si tu as d'autres articles revenant sur les années 90 (Archimedes, NextSTEP… RISC vs CISC…), n'hésite pas

      Il y a un film : Micro Men

      Micro Men is a BBC dramatisation depicting the story of Sinclair and Acorn during the early 80s. The film starts with Chris Curry and Clive Sinclair working alongside at Sinclair Radionics, with Chris leaving to setup Acorn computers in the late 1970s. Acorn then went onto produce the BBC Micro, whilst Sinclair the ZX80, ZX81 and Sinclair Spectrum. The film charts this story and ends are the computer game crash of the mid 70s, with Acorn and Sinclair both trying to make gains in each others markets. Sinclair produced the Sinclair QL whilst Acorn tried to make a mark in the Spectrum's gaming market with the Acorn Electron. Sinclair finally got sold off to Amstrad and Acorn was purchased by Olivetti.

  • # Presque en synchro

    Posté par  (site Web personnel) . Évalué à 10. Dernière modification le 11/10/20 à 13:43.

    À deux semaines près ; je vais bientôt être l'heureux possesseur d'un Acorn Archimedes A3010.
    C'est une machine qui m'a toujours fasciné, par son exotisme mais aussi sa parenté architecturale avec nos smartphones modernes.

    On peut installer un Linux 2.0.31 dessus ; dans ce cas, l'ABI est la même que sur un Linux 2.x ARM "classique". Les binaires sont donc transférables. Par exemple, ce code une fois "assemblé" marchera à la fois sur Archimedes et une autre carte ARM :

        message:
         .ascii "Salut !\n"
    
        .global main
    
        main:
          mov r0,#1        /* put 1 in R0 : stdout */
          ldr r1,=message  /* put buffer address in R1 : string */
          mov r2,#8        /* put 8 in R2 : string length */
    
          /* OABI : write() syscall */
          swi #9437188
    

    Sur un Linux plus récent, non seulement l'alignement change (on passe de l'architecture "arm" à "armel" par défaut sur Debian), ce qui fait que le binaire ne se transfère plus; mais en plus on passe de l'OABI historique à l'EABI, ce qui implique de changer le syscall à la fin:

          /* EABI : write() syscall 4 */
          mov r7,#4 */
          swi #0
    

    (ce qui, par ailleurs, marchera aussi sur Android).

    RiscOS, lui, intègre carrément un éditeur pour exécuter de l'assembleur directement. Le format est bien sûr différent, et depuis le vieil Archimedes jusqu'à la récente Raspberry Pi, reste constant grâce à des genres de macros :

               SWI "OS_Write0"  ; display registry 0 content on console
    

    C'est vraiment un excellent OS pour s'initier au bas niveau sur ARM ; un truc d'étudiant. Niveau écosystème soft, on est bien sûr bien loin derrière Tutux…

  • # MacOS

    Posté par  (site Web personnel) . Évalué à 1.

    Mouais je veux dire MacOS est passé de PowerPC, à Intel, à ARM avec les iPhone/iPads et maintenant sur ARM sur les Macs.

    Pour un OS qui n'est pas évolutif, je trouve qu'il évolue vachement !

    Il est au contraire vachement évolutif car il est basé sur un micro-noyau et la couche kernel est très fine, tu dois confondre avec la couche "Framework" et la encore, ils ont su faire évoluer leur couche applicative de manière spectaculaire en 20ans.

    • [^] # Re: MacOS

      Posté par  . Évalué à 3.

      Il faut bien distinguer l'ancien Mac OS et son remplaçant : Mac OS X.

      MacOS est l'OS des années 80/90 qui se nommait au départ System[1,7] et qui a tourné sur 68k et PowerPC.

      MacOS*X* est une évolution de l'OS OpenStep de NeXT avec le look'n feel d'Apple. Le marketing l'a nommé successivement Rapsody (1998), MacOSX (2001) puis OSX et aujourd'hui MacOS. Il a débuté sur les machines PowerPC puis Intel et bientôt ARM.

      Les premiers MacOSX proposaient Classic qui exécutait un environnement capable d'exécuter les anciennes applications compilés pour MacOS9.

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n’en sommes pas responsables.