Discussion :

[Bill Fassinou]

Le premier ordinateur portable RISC-V est désormais disponible
le DevTerm R-01 est compatible avec le Raspberry Pi CM3

Clockwork Pi vient de lancer "le DevTerm R-01" : une nouvelle variante de son portable DevTerm, revendiquant la couronne de "premier terminal portable RISC-V 64 bits au monde". Le DevTerm R-01 est équipé du "RV64IMAFDCVU", un processeur monocœur de 64 bits basé sur l'architecture RISC-V et sorti en 1983. Avec un facteur de forme inspiré du célèbre ordinateur "TRS-80 Model 100" de style "slabtop", le DevTerm R-01 un ordinateur portable doté d'un écran ultra-large de 6,86 pouces, d'un clavier intégré et d'une carte mère ClockworkPi v3.14.

Lancé en novembre 2020, mais n'arrivant pas chez les clients avant fin juillet 2021, le DevTerm est un PC portable compact conçu selon la même disposition générale que les microordinateurs classiques de type bloc-notes, comme le Kyotronic 85 de Kyocera et son dérivé, le TRS-80 Model 100. Doté d'un écran ultra-large, d'un clavier compact et d'une imprimante thermique intégrée, c'est une création impressionnante qui n'atteint pas la perfection à cause de certains problèmes logiciels. Désormais, il est également disponible dans une nouvelle version : RISC-V. Cette dernière est décrite comme "le premier terminal RISC-V 64 bits portable au monde".

En effet, la plupart des CPU utilisés dans les PC du monde entier sont basés sur l'architecture à jeu d'instructions (ISA) x86 d'Intel, tandis que les CPU et GPU utilisés dans les smartphones et autres appareils sont conçus sur la base de l'architecture Arm. Mais les deux ISA nécessitent une licence de conception, ce qui rend difficile, voire impossible, la conception de CPU pour les petites entreprises et les institutions universitaires qui ne peuvent pas se permettre de payer d'énormes redevances. Le RISC-V est une ISA développée en open source et libre qui devrait permettre de résoudre ce problème, car des universités et des entreprises participent à son développement.

Commercialisé par Clockwork Pi, une société qui développe des logiciels open source et du matériel basé sur le Raspberry Pi, à l'endroit des "développeurs libres", le DevTerm R-01 est en grande partie identique aux versions précédentes. La différence : un nouveau système sur module, que Clockwork Pi appelle le "R-01 Core", construit sur le système sur puce "Allwinner D1". Le D1, qui alimente également la carte de développement Nezha et diverses alternatives tierces, intègre un seul cœur de processeur 64 bits de 1 GHz qui met en œuvre le sous-ensemble RV64IMAFDCVU de l'architecture libre et gratuite du jeu d'instructions RISC-V.

Il n'y a pas de processeur graphique, bien que la sortie vidéo soit possible via un rendu logiciel, et il convient de noter que le modèle RISC-V contient beaucoup moins de RAM que les versions ARM du DevTerm (1 Go de mémoire DDR3, contre 2 ou 4 Go pour les versions ARM). Alors que la carte microSD est censée être livrée avec clockworkOS, le Wiki ne contient pas de lien pour la version RISC-V des systèmes d'exploitation ni aucune information sur le module R-01 Core. La société explique en outre que le DevTerm R-01 est "un modèle hautement expérimental qui nécessite une certaine expérience du système Linux et des logiciels libres".

Ne vous attendez donc pas à ce qu'il fonctionne facilement dès sa sortie de la boîte, et bien sûr, puisqu'il n'y a pas de GPU, tout graphique 3D sera rendu par un logiciel. Du côté positif, cela signifie qu'il y a maintenant un module RISC-V qui suit le facteur de forme du Raspberry Pi Compute Module 3 (CM3). Voici les caractéristiques clés du DevTerm R-01 :

• système sur module : module R-01 Core avec processeur Allwinner D1 single-core 64-bit RISC-V RV64IMAFDCVU @ 1.0GHz sans GPU, et 1GB DDR3 ;
• carte porteuse : carte mère ClockworkPi v3.14 ;
• stockage : carte microSD de 32 Go préchargée avec clockworkOS ;
• affichage : module-écran IPS de 6,86 pouces ;
• audio : double haut-parleur ;
• clavier : clavier Clockwork 65 ;
• composant pour imprimante thermique 58mm 200dpi (ne fait pas partie du kit) ;
• module de batterie pour deux batteries 18650 (les batteries ne sont pas incluses) ;
• Coques et système de fixation

À titre de rappel, "slabtop" est un boîtier de remplacement d'ordinateur de bureau qui vise à combler le fossé entre l'ordinateur de bureau et l'ordinateur portable, en offrant la portabilité d'un ordinateur portable à bas prix et la facilité de mise à jour d'un ordinateur de bureau. En d'autres termes, c'est un projet qui a pour but de prendre du matériel standard de bureau et de l'intégrer dans un boîtier portable fonctionnant sur batterie avec tous les périphériques d'entrée habituels d'un ordinateur portable. Le concept a été popularisé au cours des cinq dernières années.

Clockwork Pi propose le DevTerm R-01 à 239 dollars, ce qui en fait le modèle le moins cher de la gamme depuis que des ruptures de stock ont entraîné le retrait de la variante conçue autour du Raspberry Pi CM3, désormais difficile à obtenir. Pour ceux qui possèdent un autre modèle de DevTerm, le module RISC-V R-01 est disponible seul au prix de 29 dollars comme alternative. Mais il s'agit probablement de précommandes puisque ClockworkPi indique que le délai de livraison est estimé à environ 60 jours ouvrables en raison de la situation actuelle de la chaîne d'approvisionnement et de la logistique.

Source : le DevTerm R-01

Et vous ?

Quel est votre avis sur le sujet ?
Que pensez-vous du DevTerm R-01 ?
Pensez-vous que l'architecture RISC-V va démocratiser davantage l'industrie des semiconducteurs ?

Voir aussi

L'UE adopte l'architecture RISC-V sur supercalculateurs, les puces de 22 nm ont passé les premiers tests, en exécutant un programme « hello world »

MIPS Technologies rejoint RISC-V et passe à la norme open source standard ISA, ce qui annonce apparemment la fin de la famille des processeurs MIPS

La fondation Raspberry Pi lance le Compute Module 3, la dernière version du module Raspberry Pi destiné à être intégré dans d'autres produits

Le système de fichiers reiserfs pourrait quitter le noyau Linux en 2022. Est-il temps de supprimer reiserfs ?

[calvaire]

je comprends pas l'intérêt de vendre ca sous forme d'un pc portable. c'est inutilisable dans cette usage.
il aurait mieux value le vendre sous forme d'une carte comme un raspberry, sans écran.

on reste quand meme vachement limité, pour découvrir risc-v, faire du serveur ou de la domotique/embarqué pourquoi pas mais ça n'ira pas plus loins

[abriotde]

C est à pa connaissance le premier RiscV abordable, donc réellement grand public.

J aime bien ce système de slabtop. Personnellement je transporte souvent mon mini-PC entre la maison et le bureau. Et par rapport au PC portable on gagne la modularité.

[daerlnaxe]

Pour ma part c'est un cisc x86 intégrant certaines technologies récentes en même temps que j'aimerai bien voir. Je me casserai moins la tête sur la question du rétrogaming des jeux win9x.

[daerlnaxe]

J'imagine que certaines solutions de ce type pourraient satisfaire pas mal d'entreprises qui n'utilisent les pcs que poru du traitement de texte + éventuellement le technicien qui peut emmener un pc dans sa poche pour intervenir sur un site.

j'ai regardé ces derniers temps m'intéressant au rétro gaming, les raspberry m'intéressant mais au final limités comparés à un pc. Mais sympa pour jouer on va dire jusque vers la PS1. J'avais envie de voir pour monter un truc sous win9x aussi et je me demandais pourquoi personne ne le faisait c'est là où j'avais vu qu'en fait (si je me souviens bien) il y avait de grosses différences entre les RISC et les CISC dans la manière de traiter les instructions surtout. Mais je compte un de ces quatre me prendre quand même quelque chose de ce type, déjà pour explorer un peu dans tous les sens (faut que je bosse avant :/).. l'envie d eme faire quelque chose sour Archlinux (si je me souviens bien du nom, en gros le plus hardcore et basique mais léger et de fait on peut faire arriver à un os sur mesure.)

[calvaire]

J'imagine que certaines solutions de ce type pourraient satisfaire pas mal d'entreprises qui n'utilisent les pcs que poru du traitement de texte + éventuellement le technicien qui peut emmener un pc dans sa poche pour intervenir sur un site.

pour un usage bureautique non pas vraiment.
J'ai essayé avec le raspberry4 mais clairement c'est pas possible, la navigation internet est une catastrophe (des qu'on lance youtube par exemple) et libre office rame un peu quand même, c'est loin du confort d'un pc portable intel/amd avec ssd.
C'est utilisable pour dépanner mais pour un salarié d'entreprise au quotidien non c'est contre productif.

pour ce riscv sans accélération graphique ce sera juste pas possible. Et meme avec, le cpu est pas assez puissant pour lancer une suite bureautique (comme libre office) ou un navigateur web.

[daerlnaxe]

Ah, merci pour le retour, j'ai lu un sur les CISC et les RISC il y a peu mais je pensais pas que ça pouvait se traduire ainsi aussi.

[calvaire]

Ah, merci pour le retour, j'ai lu un sur les CISC et les RISC il y a peu mais je pensais pas que ça pouvait se traduire ainsi aussi.

ah non ma remarque n'a rien à voir avec la différence entre un cpu CISC et RISC.

Arm c'est du risc et on a de très bon soc, le snapdragon 8 gen 1 par exemple est aussi puissant qu'un cpu cisc intel/amd entré de gamme et est largement suffisant pour faire tourner un pc bureautique et des petits jeux.

On fait des cpu arm serveur et je suppose qu'on pourrait faire des cpu arm haut de gamme capable de rivaliser avec les haut de gamme intel/amd (mais avec un tdp qui explose y'a pas de magie)

CISC ou RISC en vrai aujourd'hui c'est un faux débat je pense, les architectures sont tellement optimisé que concrètement il n'y a pas de gain en perf ou en conso.
A conso équivalente un cpu x86 intel a les mêmes perf qu'un arm.

Les choix de lincensing et d'écosysteme me semble plus important que l'architecture en elle même.
Si je suis un constructeur, je sais que je pourrais pas vendre des pc windows arm (car pas de logiciels natif dessus)
Je sais que je pourrais pas vendre des smartphones android intel (peu d'applications compilé en x86 et intel ne vends pas des soc juste un cpu avec un igpu, il n'existe pas de puce avec modem 4g/5g intégré par exemple, ni d'isp pour gérer la partie photo)

[tontonCD]

Curieux, il y a un côté un peu moche s on compare à un ordi, mais tellement vintage si on compare aux produits des années 80 (Z80, ...) et tellement plus puissant...
Pour la catégorie, je pense qu'il et plutôt à comparer au https://www.raspberrypi.com/products/raspberry-pi-400/ ; mais en bien plus cher ; c'est vrai qu'il y a un écran. La carte seule vaut 40$.
Usage... pour le web je sais pas, mais pour prendre des notes en fac, pas mal. Pour développer (à destination des cartes plus simples) ce doit être beaucoup plus confortable aussi.
L'alimentation intégrée, par batteries 18650, c'est top comme idée.

[daerlnaxe]

ah non ma remarque n'a rien à voir avec la différence entre un cpu CISC et RISC.

Arm c'est du risc et on a de très bon soc, le snapdragon 8 gen 1 par exemple est aussi puissant qu'un cpu cisc intel/amd entré de gamme et est largement suffisant pour faire tourner un pc bureautique et des petits jeux.

On fait des cpu arm serveur et je suppose qu'on pourrait faire des cpu arm haut de gamme capable de rivaliser avec les haut de gamme intel/amd (mais avec un tdp qui explose y'a pas de magie)

CISC ou RISC en vrai aujourd'hui c'est un faux débat je pense, les architectures sont tellement optimisé que concrètement il n'y a pas de gain en perf ou en conso.
A conso équivalente un cpu x86 intel a les mêmes perf qu'un arm.

Les choix de lincensing et d'écosysteme me semble plus important que l'architecture en elle même.
Si je suis un constructeur, je sais que je pourrais pas vendre des pc windows arm (car pas de logiciels natif dessus)
Je sais que je pourrais pas vendre des smartphones android intel (peu d'applications compilé en x86 et intel ne vends pas des soc juste un cpu avec un igpu, il n'existe pas de puce avec modem 4g/5g intégré par exemple, ni d'isp pour gérer la partie photo)

C'est pas ce que j'ai lu, ensuite apparemment tu ne peux pas faire tourner tous les OS à cause justement de l'architecture, de ce que j'ai pu voir tu as les Vortex, j'ai rien trouvé d'autre pour du win9x, je m'interrogeais d'ailleurs sur le fait qu'on n'en voyait pas, on ne trouve que des versions graphiquement similaires. D'après ce que j'ai pu lire c'est pas une question de puissance dans le cas dont je parle mais de manière dont les instructions sont gérées. Mais je reste ouvert, si des gens ont entrepris la démarche (vu que je n'ai pas d'équipement pour le moment pour tester), je suis friand de retours.

[calvaire]

ensuite apparemment tu ne peux pas faire tourner tous les OS à cause justement de l'architecture, de ce que j'ai pu voir tu as les Vortex

Tu peux faire tourner n'importe quel os sur n'importe quel architecture, il suffit juste de le compiler pour l'architecture visé (et de recoder quelques fichiers d'assembleurs)

j'ai rien trouvé d'autre pour du win9x

win9x sont des os abandonnée et au code source fermé donc non effectivement tu pourras pas utiliser ces os sur autre chose que du x86.
Par contre les Windows CE utilise le même noyaux que windows 98, lui a été compilé et utilisé sur des cpu arm

A la même époque aussi Windows NT4 a été compilé sur des processeurs X86, Alpha, MIPS ou PowerPC.
Windows server 2003 tournait sur des proc Itanium.

et Linux tourne sur tout


le code source de msdos a été libéré il y'a quelques années, il doit surement exister des forks arm
freedos et reactos tourne sur des proc x86 et arm

[daerlnaxe]

je sais que tu peux faire tourner ton code du moment que tu compiles sur la machine (enfin... en gros) Mais comme tu le dis code source fermé, donc en résumé tu ne peux pas. Merci pour les infos ceci dit (je suis sur win3x aussi en forum). Freedos n'est pas MS Dos et tu as du matériel qui peut ne pas être reconnu etc etc.. le problème reste entier si tu veux. Si ça te passionne aussi tu trouveras d'autres motivés et des fans de vieilles machines là bas. Du coup ça donne du react os + wine pour les jeux... c'est l'option pauvre. A l'heure actuelle c'est bloqué à part en se servant d'un hyperviseur, tu as les x86 vortex qui peuvent théoriquement faire tourner les win9x (faudra écrire les drivers par contre), ils font tourner xp sans soucis selon un fournisseur anglais que j'ai contacté. Franchement faudrait vraiment que ça tombe dans le libre je vois pas ce qu'ils ont à perdre et ça ferait un paquet d'heureux.

[calvaire]

mais pourquoi tu veux faire tourner un windows 9.x sur du arm je comprends pas ?
de toute façon ces os tu peux plus les installer même sur des machines x86 moderne, tu trouveras aucun driver et ce sera donc inutilisable quand bien même sa booterai (je suis quasiment sur que t'aura un bsod avant).
si tu veux les utiliser tu dois utiliser une vm ou mieux encore émuler un vieux cpu avec qemu, pour le coup qemu est utilisable sur des plateforme arm pour faire tourner tes vieux os. Tu as sur androd l'application limbo pc emulator qui est pas mal.


risc ou cisc c'est franchement pareil de nos jours, d’ailleurs un x86 aujourd'hui c'est plus vraiment du CISC (depuis au moins 20ans d'ailleurs), mais de "l'hybride".
Aujourd'hui un processeur x86 fonctionne en ayant un décodeur assez lourd dans le front-end, qui accepte les instructions x86 et les convertit en un format interne optimisé, que le back-end peut traiter.
La raison pour laquelle Intel ou AMD utilise un ensemble de micro-instructions de type RISC en interne est qu'elles peuvent être traitées plus efficacement.

Niveau conso on sait faire des proc x86 de moins d'1watt comme arm pour l'embarqué, le Intel 8086 grévé en 3000 nm d'ailleurs pouvait consommer seulement 0.25w en faible charge et 1.8w a pleine puissance.

[daerlnaxe]

Je suis déjà au courant je t'ai dis que j'utilisais des hyperviseurs, quand à QEMU t'as un post de ma part où je demande un coup de main pour cross compiler depuis ubuntu vers Windows10 et un autre en c++, à part Chrtophe personne n'est venu m'aider, le but étant par la suite d'utiliser un , voire des patchs. Quand tu dis RISC et CISC c'est pareil de nos jours non pas vraiment, c'est plutôt du côté des OS que ça a changé. Mais bon ça sert à rien d'en parler là, si tu veux te lancer justement pour essayer de trouver un moyen de faire tourner un vieil os pour avoir un truc relativement fidèle le mieux c'est de venir sur win3x ou qu'on fasse un post dédié. Y'a une startup asiatique qui devait justement recommencer à faire des microcontrolleurs qui auraient pu convenir mais c'est au point mort apparemment.

Et ce pourquoi je veux faire tourner et bien principalement pour du retrogaming comme expliqué quand je parlais de React OS, les conditions actuelles pour retrouver de vieux jeux sont des solutions "du pauvre", ça consiste soit à faire du wrapper (quand ça fonctionne et donc pas avec tous les jeux) , soit à balancer dans wine sous réserve de compatibilité etc avec les vieux jeux, peut mieux faire. Au final si t'as une grosse collection c'est un travail de titan, ça foire énormément, c'est facilement éclaté entre 10 solutions différentes... Un paquet de patchs de la communauté qui se mêlent de rajouter des "QOS" alors que ça affecte le gameplay, etc etc... Idée, préserver l'intégrité de ces jeux dans le temps, en favorisant leur environnement d'origine. Justement j'ai opté pour QEMU mais j'ai un support de la 3D que je veux intégrer sur du windows host. C'est prévu que je fasse un tuto pour la communauté, je peux le faire pour la 2D mais pas encore pour le support 3D. J'ai trouvé en sus un très bon logiciel qui m'évite de le faire moi (j'étais pour), qui applique des shaders soit en interceptant les fenêtres soit sur tout le bureau ce qui évite le besoin d'un scanline generator.

[Kannagi]

On fait des cpu arm serveur et je suppose qu'on pourrait faire des cpu arm haut de gamme capable de rivaliser avec les haut de gamme intel/amd (mais avec un tdp qui explose y'a pas de magie)

Celà existe , y'a Apple M1
(Le M1 Ultra est vraiment une version haut de gamme , et à la puissance d'un Threadripper 3990X).

. Quand tu dis RISC et CISC c'est pareil de nos jours non pas vraiment, c'est plutôt du côté des OS que ça a changé

D'un point de vue de la micro-architecture "oui" ,enfin un CISC pur est très différent d'un RISC.
Mais ton soucis d'OS n'a absolument rien n'a voir avec le RISC ,si c'était le cas ,ton OS marcherais sur tout les processeur CISC (genre M68000 ou le 6502) , et je peux t'assurer que ça serait une prouesse technique de faire marcher un OS un poil évolué sur du 6502
Apparament tu parle de Windows/MS-DOS qui sont tout les deux des OS développé de base pour du x86 , et donc il te faut du "x86" , peu importe que ça soit du CISC ou RISC.
Et justement de nos jours ce qui a changé est la prévalence des processeurs RISC , les proceseurs CISC sont "mort" ,sauf si on compte Intel/AMD , et encore comme dit plus haut , ce ne sont plus de vrai processeur CISC.

[daerlnaxe]

Sauf que vous deux vous partez du principe qu'on aurait accès aux sources, moi pas déjà. Ensuite le RISC comme son nom l'indique est une architecture à jeu d'instructions réduites, le CISC a jeu d'instructions complexe, alors oui avec la puissance actuelle y compris sur un RISC on pourrait le faire tourner sous réserve déjà d'avoir la possibilité d'en faire une version avec une compilation pure, sauf que la meilleure option serait plus de revoir complètement l'os à moins de vouloir faire une usine à gaz. C'est "juste" deux architectures différentes et pas qu'une question pur x86. Sur le M68000 tu dis que ça pourrait sans soucis sauf que l'ALU a une largeur de 16 bits entrainant plus de cycles etc .. Bref des architectures différentes, je ne me souviens pas avoir dit ou sous entendu que tous les CISC étaient similaires. Et je rappelle que j'ai parlé du x86 Vortex ça n'était pas pour rien. C'est un peu comme les espèces vivantes tu as des familles et tu vas rentrer ensuite dans les spécificités entre les races etc etc.. Je ne vois pas où j'ai dit le contraire... J'ai simplement marqué des textes assez génériques pour ne pas s'embarquer dans un long texte car il faudrait un énorme pavé bien plus que celui ci pour tout expliquer. Surtout si on doit tout prendre en compte pour ce que je voudrais faire.

l y avait de grosses différences entre les RISC et les CISC dans la manière de traiter les instructions surtout

Je ne vois pas en quoi c'est faux.

Que ça pouvait se traduire ainsi

C'est l'application pratique d'un point théorique

Mais comme tu le dis code source fermé, donc en résumé tu ne peux pas

J'ai bien expliqué que dans tous les cas on était bloqués.

Quand tu dis RISC et CISC c'est pareil de nos jours non pas vraiment, c'est plutôt du côté des OS que ça a changé

Ce qui est le cas, c'est au niveau de la compilation qu'il va falloir segmenter les instructions pour que ça soit adapté au RISC, la manière de coder peut influencer également dès le début etc ... Si tu considères l'OS du point de vue source uniquement, en effet tu as des possibilités bien plus importantes, si tu considères l'OS comme ce que l'on te présente en bout, donc compilé... Ce qui est aussi une grande différence entre ce que tu vas trouver sur linux et sur windows. Alors tes possibilités sont restreintes. Avec du pros/cons d'ailleurs.

Donc pourquoi faire un faux débat j'ai pas dit que ça servait à rien, j'ai juste dit que ce n'était pas une solution adaptée à ce que je cherchais. Que c'était lié à l'architecture et ben c'est le cas en l'état... là ça fait un peu discussion de "je connais les grands principes" donc je fais tout pour le montrer. Est ce qu'en adaptant un os il va tourner sur une machine plus puissante et plus récente, ça parait logique que si tu modifies celui ci ça soit possible, vous pouvez le faire ? Moi ça m'intéresse vraiment en plus, mais curieusement je ne trouve jamais personne quand il s 'agit de se lancer sur des trucs de ce type.
Je pensais en revanche que ça pouvait être bien adapté à la bureautique, bon on me dit que non ok... Je vais pas ennuyer la personne pour le moment je prends l'info je mets de côté quand je m'en prendrais un je ferai mes propres tests.

Encore une fois j'ai QEMU a cross compiler, ne vous gênez pas pour venir me filer un coup de pouce au lieu de faire de la querelle de clocher. Personnellement j'ai pas spécialement d'intérêt à dire ça c'est possible et ça, ça ne l'est pas... Je me contente juste de noter et de chercher des solutions qui me permettent d'avancer.

[Kannagi]

Ensuite le RISC comme son nom l'indique est une architecture à jeu d'instructions réduites, le CISC a jeu d'instructions complexe, alors oui avec la puissance actuelle y compris sur un RISC on pourrait le faire tourner sous réserve déjà d'avoir la possibilité d'en faire une version avec une compilation pure, sauf que la meilleure option serait plus de revoir complètement l'os à moins de vouloir faire une usine à gaz.

C'est souvent le soucis quand on parle de RISC et CISC , si on est pas dans la micro-architecture , on comprend mal , RISC devrait se traduire par instruction plus "simple" , et non réduite.
Et encore simple d'un point de vue du matériel , pas de l'"humain"

C'est "juste" deux architectures différentes et pas qu'une question pur x86. Sur le M68000 tu dis que ça pourrait sans soucis sauf que l'ALU a une largeur de 16 bits entrainant plus de cycles etc .. Bref des architectures différentes, je ne me souviens pas avoir dit ou sous entendu que tous les CISC étaient similaires. Et je rappelle que j'ai parlé du x86 Vortex ça n'était pas pour rien. C'est un peu comme les espèces vivantes tu as des familles et tu vas rentrer ensuite dans les spécificités entre les races etc etc.. Je ne vois pas où j'ai dit le contraire...

Je n'ai jamais dit que le M68000 et le x86 sont similaire (sauf de façon ironique) , c'est toi qui laissé pensé que ton soucis c'est du RISC , et donc si je poussais ton idée plus loin tout les CISC sont équivalent.

Bref , tu débat dans le vide, ton soucis, c'est juste "x86" point barre , les concept de micro architecture avancé n'est pas la source de ton problème.

Ce qui est le cas, c'est au niveau de la compilation qu'il va falloir segmenter les instructions pour que ça soit adapté au RISC, la manière de coder peut influencer également dès le début etc ... Si tu considères l'OS du point de vue source uniquement, en effet tu as des possibilités bien plus importantes, si tu considères l'OS comme ce que l'on te présente en bout, donc compilé... Ce qui est aussi une grande différence entre ce que tu vas trouver sur linux et sur windows. Alors tes possibilités sont restreintes. Avec du pros/cons d'ailleurs.

Donc pourquoi faire un faux débat j'ai pas dit que ça servait à rien, j'ai juste dit que ce n'était pas une solution adaptée à ce que je cherchais. Que c'était lié à l'architecture et ben c'est le cas en l'état... là ça fait un peu discussion de "je connais les grands principes" donc je fais tout pour le montrer. Est ce qu'en adaptant un os il va tourner sur une machine plus puissante et plus récente, ça parait logique que si tu modifies celui ci ça soit possible, vous pouvez le faire ? Moi ça m'intéresse vraiment en plus, mais curieusement je ne trouve jamais personne quand il s 'agit de se lancer sur des trucs de ce type.
Je pensais en revanche que ça pouvait être bien adapté à la bureautique, bon on me dit que non ok... Je vais pas ennuyer la personne pour le moment je prends l'info je mets de côté quand je m'en prendrais un je ferai mes propres tests.

C'est toi qui est parti de ce débat, surtout que tu ne semble pas du tout maîtriser le sujet

Est ce qu'en adaptant un os il va tourner sur une machine plus puissante et plus récente, ça parait logique que si tu modifies celui ci ça soit possible, vous pouvez le faire ? Moi ça m'intéresse vraiment en plus, mais curieusement je ne trouve jamais personne quand il s 'agit de se lancer sur des trucs de ce type.

Encore une fois j'ai QEMU a cross compiler, ne vous gênez pas pour venir me filer un coup de pouce au lieu de faire de la querelle de clocher. Personnellement j'ai pas spécialement d'intérêt à dire ça c'est possible et ça, ça ne l'est pas... Je me contente juste de noter et de chercher des solutions qui me permettent d'avancer.

Ce n'est pas le sujet du topic de résoudre tes soucis avec QEMU ou de faire tourner un vieux OS sur ARM ou autre ,(perso je m'en fous royalement ! ).
Le topic est ici de parler d'un PC sous RISC-V (qui est une architecture open source).

C'est l'impression que tu tourne la discussion à ton soucis perso , qui n'est pas le mien (et qui semble pas être celle des autres non plus ).
Si tu as un soucis avec ça , tu poste sur un topic dédié pour t'aider, si tu ne trouve pas d'aide c'est que personne ne sait tout simplement.

[daerlnaxe]

Sauf qu'ici encore une fois tu me fais dire ce que je n'ai pas dit (simple / réduite).


Là comme le reste le seul but est de flatter ton égo en rabaissant si j'avais dit simple tu m'aurais balancé que l'acronyme ce n'était pas ça. Tu es venu l'égo en avant, je sais pas ce que vous avez à prouver mais c'est pas mon soucis.

Je n'ai pas non plus dis que tu avais dit que le x86 et le M68000 étaient similaires, je ne vois absolument pas où j'ai pu laisser croire ça, justement je reprends ton exemple qui témoigne de l'incompatibilité. J'ai bien compris que tu faisais l'analogie par rapport à l'architecture CISC, tu projettes comme Calvaire que tu as un abruti en face. C'est très agréable comme conversation.. .Vraiment. En fait depuis le début moi j'essaie d'être respectueux mais j'aurais pu vous répondre par
"No shit, Sherlock ? . Et j'étais repassé pour rajouter quand même que dès lors que tu as accès aux sources, à part des limitations en puissance on va dire schématiquement qu'en fait tu pourrais +/- tout faire potentiellement. Après tout tu pourrais très bien réadapter chaque programme, wrapper certains etc etc...

Non, mon soucis n'est pas "juste x86 point barre" puisque justement si l'os tombait dans le libre, le juste x86-point-barre pourrait se régler. Donc avec ta logique on plie l'affaire plus de x86 donc l'affaire est enterrée, or ce n'est .. qu'un OS, donc adaptable pour peu qu'on dispose du code source.

C'est toi qui est parti de ce débat, surtout que tu ne semble pas du tout maîtriser le sujet

Qui est ton postulat d'où tes posts méprisants alors qu'ils ne prennent pas tout en compte.

Ce n'est pas le sujet du topic de résoudre tes soucis avec QEMU et de faire tourner un vieux OS sur ARM ou autre ,(perso je m'en fous royalement ! ).

et bien ferme là et trace, je n'ai pas exposé mes problèmes avec QEMU j'ai répondu à une question qui m'était posé, là aussi tu as des problèmes de compréhension ? En attendant tu viens me dire que je n'y connais rien mais tu ne t'es jamais attaqué au problème. C'est plus facile de rester dans sa zone de confort surtout en venant pondre des messages pour rabaisser les gens qui essaient justement de considérer un problème par tous ses angles. Et je réitère que ce n'est pas moi qui ait lancé là dedans, mes posts étaient très sommaires car je savais d'avance que j'allais tomber sur des gens qui ont un comportement comme le tien.

C'est l'impression que tu tourne la discussion à ton soucis perso , qui n'est pas le mien (et qui semble pas être celle des autres non plus )

Ca n'a jamais été le cas, je n'ai jamais cherché à rentre dans les détails c'est en raison de la manière dont on me répond que j'explique.

Si tu as un soucis avec ça , tu poste sur un topic dédié pour t'aider, si tu ne trouve pas d'aide c'est que personne ne sait tout simplement.

C'est déjà ce que j'expliquais donc un re "no shit Sherlock" donc en gros par contre tu viens parler mais dès qu'on te parle de venir donner un coup de main y'a plus personne et tu te mets tout bonnement à tourner la chose pour rabaisser la personne et valoriser ton égo.

Je vais voir s'il y a un mode bl pour éviter de se côtoyer vu les frictions, le site s'en portera que mieux, sinon je me bornerai à cette réponse

[Kannagi]

Sauf qu'ici encore une fois tu me fais dire ce que je n'ai pas dit (simple / réduite).


Là comme le reste le seul but est de flatter ton égo en rabaissant si j'avais dit simple tu m'aurais balancé que l'acronyme ce n'était pas ça. Tu es venu l'égo en avant, je sais pas ce que vous avez à prouver mais c'est pas mon soucis.

C'est une traduction littéral , si je dis plus "simple" ,c'est que le mot "réduit" est souvent très mal interpréter.
Parce que cela peut tout simplement être compris par : Le CISC possède plus d'instruction (ce qui est faux , tu as plein d’exemple contraire).
La suite d'ailleurs explique assez bien : "qui se caractérise par des instructions de base aisées à décoder, uniquement composées d'instructions simples"

Je n'ai pas non plus dis que tu avais dit que le x86 et le M68000 étaient similaires, je ne vois absolument pas où j'ai pu laisser croire ça, justement je reprends ton exemple qui témoigne de l'incompatibilité. J'ai bien compris que tu faisais l'analogie par rapport à l'architecture CISC

Je cite :

C'est "juste" deux architectures différentes et pas qu'une question pur x86. Sur le M68000 tu dis que ça pourrait sans soucis sauf que l'ALU a une largeur de 16 bits entrainant plus de cycles etc ..

Et ce n'est pas ce que je dis justement

Non, mon soucis n'est pas "juste x86 point barre" puisque justement si l'os tombait dans le libre, le juste x86 point barre pourrait se régler. Donc avec ta logique on plie l'affaire plus de x86 donc l'affaire est enterrée, or ce n'est .. qu'un OS, donc adaptable pour peu qu'on dispose du code source.

Comme tu n'as pas le code source, ton soucis est bel et bien l'architecture PC et x86

et bien ferme là et trace, je n'ai pas exposé mes problèmes avec QEMU j'ai répondu à une question qui m'était posé, là aussi tu as des problèmes de compréhension ? En attendant tu viens me dire que je n'y connais rien mais tu ne t'es jamais attaqué au problème. C'est plus facile de rester dans sa zone de confort surtout en venant pondre des messages pour rabaisser les gens qui essaient justement de considérer un problème par tous ses angles. Et je réitère que ce n'est pas moi qui ait lancé là dedans, mes posts étaient très sommaires car je savais d'avance que j'allais tomber sur des gens qui ont un comportement comme le tien.

Je ne doute pas que tu connaisse tout mon parcours, pour que tu puisse affirmer que je suis dans ma zone de confort.

Sinon oui ,tu as lancé le sujet clairement , relis toi , personne n'a parlé de RISC / CISC , ni parlé de QEMU et Windows a part toi
Tu veux pas en débattre, n'en discute pas !

tu projettes comme Calvaire que tu as un abruti en face. C'est très agréable comme conversation.. .Vraiment. En fait depuis le début moi j'essaie d'être respectueux mais j'aurais pu vous répondre par
"No shit, Sherlock ? . Et j'étais repassé pour rajouter quand même que dès lors que tu as accès aux sources, à part des limitations en puissance on va dire schématiquement qu'en fait tu pourrais +/- tout faire potentiellement. Après tout tu pourrais très bien réadapter chaque programme, wrapper certains etc etc...

Qui est ton postulat d'où tes posts méprisants alors qu'ils ne prennent pas tout en compte.

C'est déjà ce que j'expliquais donc un re "no shit Sherlock" donc en gros par contre tu viens parler mais dès qu'on te parle de venir donner un coup de main y'a plus personne et tu te mets tout bonnement à tourner la chose pour rabaisser la personne et valoriser ton égo.

Je vais voir s'il y a un mode bl pour éviter de se côtoyer vu les frictions, le site s'en portera que mieux, sinon je me bornerai à cette réponse

Je pense que tu souffre d'un gros complexe d'infériorité

Sinon j'ai aucun soucis avec mon égo , par contre la micro architecture est mon domaine et je triggered assez facilement quand je lis certain post !

[daerlnaxe]

Moi je pense que c'est surtout toi dans ce cas là vu la manière dont tu parles aux autres, donc évite de projeter j'étais même pas venu débattre car ce n'est pas le lieu et tu fais du littéral sciemment pour te trouver des excuses. Je n'ai JAMAIS parlé de CISC VS RISC, au sens débat, jamais de chez jamais c'est toi qui a cru parce que Calvaire a apparemment crû ça que j'étais venu dans ce débat là, peut être êtes vous conditionnés par d'autres discussions mais je n'ai JAMAIS eu cette démarche. Je parle simplement différences, de manière objective, selon les besoins et tu viens au final me rebalancer ce que je sais DEJA, le verrouillage du problème et qui n'est peut être pas une question de CISC vs RISC selon ta conception mais qui au final ne le serait pas non plus d'un point de vue x86 dès lors qu'on a accès aux sources, tu y avais songé ? Et il y aura d'autres architectures, d'autres OS etc etc... La question repose sur le COMMENT préserver et je ne l'ai pas posé ici ce qui aurait été le seul débat que j'aurais voulu avoir, et encore débat.. bien grand mot, discussion plutôt. Donc t'as les burnes à l'envers trouve toi quelqu'un d'autre, j'ai pas du tout envie de m'emmerder avec des discussions toxiques, avec des gens qui me prennent pour un con comme si je ne savais pas ce qu'était un hyperviseur, un x86, un x64 et j'en passe... Qu'on complémente ce que je ne sais pas, je dis un grand OUI, qu'on détourne mes propos, qu'on invente sur mon sujet et qu'on me réexplique exactement ce que je viens moi même de dire non.. Non. Est ce qu'en l'état c'est verrouillé ? Non sans blague je n'avais pas remarqué... C'est le serpent qui se mord la queue.
Si je voulais ça je serais sur Twitter, si je suis ici c'est pour dialoguer avec des gens qui sont bien plus intelligents et un minimum de courtoisie.

l'exemple de la définition de RISC est un excellent exemple de ton comportement comme celui de Calvaire... "gnagna les gens" je suis les autres ? est ce que tu m'as demandé avant comment j'interprétais ça ? Si tu l'avais fait tu aurais vu que je parlais déjà avant de la manière dont étaient traitées les instructions ,je n'ai pas été détaillé mais ça signifiait bien que je n'interprétais pas ça comme "réduites" au sens deux instructions qui se courent après, mais bien comme ayant compris qu'il y avait une gestion différente. Je n'ai peut être pas en tête le lexique exact d'autant que si je me loupais sur un terme avec des gens comme toi ça remettrait une couche, mais j'ai largement compris les principes. Et pardon mais si tu peux me définir un phénomène d'Hystérésis ou un effet HALL pour moi tu as compris même si tu ne cites pas
les termes.

Je suis également très circonspect dans ma manière d'aborder les choses, contrairement à vous deux qui êtes dans le péremptoire. Or ici comme je l'ai expliqué vous avez des définitions très arrêtées des choses. Alors que justement un tel sujet va attirer des gens qui ne sont pas dans cet état d'esprit. Donc au lieu de spéculer sur ce que j'aurais pu insinuer, posez moi des questions, je suis pas du tout dans les guéguerres à deux balles.