Discussion :

[Kannagi]

Je m'excuse pour le titre , mais c'est souvent comme ça quand on présente un nouveau processeur en général !

Depuis pas mal d'années que je programme en assembleur que je m’amuse a tester un nombre incalculable de processeur et de machine.
A force , j'ai eu ma vision du proc (et de l'ordinateur) "idéale".

Pas que mon idée naîtra un jour , mais disons que j'aimerais avoir l'avis de connaisseurs , je n'ai pas envie de créer une machine "fantaisiste" qui serait irréalisable.
Le but est surtout de créer un émulateur pour pouvoir le tester avec au plus proche des contraintes réel, et savoir que mon idée est bonne (ou pas) me satisfera dans les deux grandement.

Et puis j'attends depuis facile 10 ans de nouveau CPU autre que du x86 pour le grand public , mais ça se fait rare ou alors c'est un CPU vraiment peu puissant (le RasPi , même si le dernier commence à être pas mal).
Mais j'ai assez hésité pour présenté ce genre de projet , parce que oui , c'est un projet un peu "fou" je l'accorde (et souvent peu sérieux ), mais cela aurait dù (à mon humble avis) l'initiative de gros industriel

Bref revenant à notre sujet , j'explique un peu les termes :
VLIW , un type d'architecture ,comme le CISC ou le RISC
*OoO = Out of Order , technique d'optimisation de la pipeline "automatique"
*in order , c'est le contraire , aucune optimisation et le compilo le gère lui même en partie.
*superscalaire , technique pour exécuter plusieurs instructions en même temps
(pour vulgariser en quelque ligne).

Alors mon idée est de faire un proc VLIW , et là ceux qui connaisse l'histoire de l'informatique font me dire "oulà , c'est casse gueule" , oui je suis pas le premier à avoir essayer Sony (avec l'Emotion Engine de la PS2 , le CELL avec la PS3) , Intel (avec la gamme Itanium) , ou même le fameux Transmeta (Crusoe et Efficeon) qu avait fait beaucoup parlé de lui à l'époque (notamment qu'il faisait de la conversion du x86 /VLIW à la volée ).
Bref aucun a vraiment bien marché et tous ont eu le même point commun , un proc complexe à programmer ,et celui que je vais vous présenter ne fera pas exception , mais la différence c'est que de nos jours on a Clang et qu'il permet de faire du code intermédiaire suffisamment intéressant pour pouvoir à mon avis , le transformer et l'optimiser sur un proc plus "exotique".

Je répondrais à une question si on me dit "mais pourquoi ne pas utiliser RISC-V ?", eh ben parce que de un ,je veux pas faire du RISC , et secundu , le souci de faire du RISC-V à mon sens ,et que toute l'optimisation du proc ne fait pas partie de l'ISA , et je dirai qu'il est à mon avis peu probable qu'on aurait en open source un code Verilog ou VHDL avec de l'OoO plus performant que Intel ou AMD.
Et bien sur ben je ne veux pas faire de OoO (je pense que c'est une mauvaise idée), et le in order superscalaire pour l'avoir fait sur de nombreux proc , me semble évident que ça ne sera pas la façon la plus performante pour faire un proc.

Alors pour revenir sur le proc , c'est un proc qui veut simplifier le design au maximun , mais aussi d'atteindre au mieux les chiffres théorique , et pour cela les consoles de Sony donne une partie de la solution , il faut pouvoir précharger au cache en même temps que l’exécution (cela veut dire que le compilo ou le programmeur gère le cache).
Et si c'est bien foutu , on peut éviter la plupart des "caches miss" (sur un proc actuelle c'est une centaine de cycle ).
Alors ici je parle de façon vulgariser , ça serait faux de parler de cache , en général on parle juste de mémoire SRAM interne ou de scrachpad.
Et l'itanium était une bonne idée de pouvoir rendre le VLIW un peu plus "dynamique" , le soucis du VLIW qui est trop statique , c'est qu’on a tendance à mettre pas mal d'instruction "nop" et donc le cache en souffre pas mal.
Donc j'ai fait en sorte qu'on puisse changer un peu le nombre d'instruction qu'on exécute en parallèle.
Un autre point , c'est que une mémoire gérer par le programmeur ne peut pas gérer tout les cas ,donc j'ai inclus aussi une mémoire cache du type Direct Mapped.

Pour donner une image de ce que ça donne :


(et du coup c'est bien plus simple qu'un Intel ou AMD Zen 2 Superscalaire Out of Order) : https://en.wikichip.org/wiki/File:ze...re_diagram.svg

L'avantage de ce genre d'architecture c'est que ça réduit de beaucoup le nombre de transistor , ça simplifie beaucoup aussi sa conception , et donc on gagne aussi en terme de dissipation de chaleur et de watts consommé , tout en ayant (normalement ) des très bonnes perfs

J'ai mis ici 128Kio de SRAM parce que la façon de programmer sur ce genre de machine et de faire un double buffer.
Je m'explique vous utilisez la moitié (64 Kio) , et pendant que vous faite vos calcul tranquille dessus , vous préchargez les donner suivante dans l'autre buffer ,sans que cela stop le CPU , donc comme ça ,vous perdez aucun temps pour vos calcul quand vous voulez lire la RAM (et ainsi de suite , vous switcher entre les deux buffers).
Tout cela se fait via un DMA (que j'ai pas préciser ici mais que le MMU est collé sur le DMA , vu que c'est le seul point d'entrée/sortie)

Pour la prédiction de branchement il n'y en n'a pas , comme le montre le graphisme , le branchement (ou un call/ret) se fait sur le decode , donc il se fait sur 1 cycle + 1 cycle de delay.
Cette optimisation existe depuis longtemps , mais elle à été "abandonné" , parce qu'elle est complexe à mettre en place (surtout sur un x86 ou le decode se fait en plusieurs cycles ).
C'est une optimisation qui ne peut se faire que sur un proc très "simple" (la plupart des processeurs MIPS ayant cette optimisation).

Pour la pipeline , je vise un truc en 2 + 4-8 stages :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
IF : Fetch (load opcode Memory SRAM instruction)
ID : decode instruction / load register flag
RR : Read Register general
EX : execution
MEM : L/S memory SRAM data
WB : write back ( write register)


loadm/storem 6+ cycles (rr,exe,dma,---,enddma,mem,wb) (memory DRAM)
loadc/storec 5+ cycles (rr,exe,mem,mem,wb) (load/store cache)

load 4 cycle (rr,exe,mem,wb)
store 4 cycle (rr,exe,mem,nop)
all reg/imm-reg/reg 3 cycle (rr,exe,wb)
mul 4 cycle (rr,exe,exe,wb)
div 5 cycle (rr,div,div,div,wb)

float 5 cycle (rr,fexe,fexe,fexe,wb)
fdiv 8 cycles (rr,fdiv,fdiv,fdiv,fdiv,fdiv,fdiv,wb)

C'est un proc donc qui peut faire 2-4 instructions par cycles.
Il peut switcher entre les deux (avec un delay du coup d'un cycle).
Je ne veux pas faire plus , parce que de un , par expérience , si on fait plus , on va se trouver avec pas mal de "nop" , et secundo , j'ai assez du mal à voir comment on fait plus.
Sur ce proc avec un delay en moyenne de 2-3 cycles pour les instructions les plus courantes , ça laisse 4-6 instructions (voir le double) à remplir , c'est assez énorme.

Je sais que les Intel et Ryzen peuvent avoir des pic de 4-5 IPC dans certain cas.

J'ai tenté de savoir combien ça prendrait en terme de transistor (et la forme du die) :



Le nombre me semble correct ,(même si je le compare avec le CELL qui avait je crois 200 ou 300MT par exemple ).
Je n'explique pas forcément comment j'ai calculé en détails (une partie est calcul via tout simplement avec la photo du die des CPU existant, vu que certain photo montre où se trouve les unité de calcul , il suffit juste de faire un produit en croix ensuite par rapport à la ratio pixel/nombre de transistor).
On est bien sur loin des milliard de transistor actuellement (je crois que les Ryzen 3600 6cores/12 threads fait 3800MT).
Donc oui si avec 800MT , je peux avoir 16 cores , ça serait bien

Ah et je dirais que cela demandera forcément peut être de "refaire"un OS vu les caractéristique spécifique pour gérer un exécutable ici.
J'avais écris rapidement la Memory Map de la future machine :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
Memory MAP

0x00 0000 0000 - 0x00 FFFF FFFF ------- I/O (+DMA)

0x01 0000 0000 - 0x01 FFFF FFFF ------- L2 & L3 cache
0x02 0000 0000 - 0x02 FFFF FFFF ------- Sound DRAM (4 GB max )
0x03 0000 0000 - 0x03 FFFF FFFF ------- VRAM1      (4 GB max )
0x10 0000 0000 - 0x1F FFFF FFFF ------- VRAM2 (GPU)(64 GB max )

0x20 0000 0000 - 0x7F FFFF FFFF ------- SSD RAM    (384 GB max )
0x80 0000 0000 - 0xFF FFFF FFFF ------- RAM        (512 GB max )

Memory MAP SRAM/scratchpad
0x00000 - 0x1FFFF ------- SRAM Data
0x00000 - 0x1FFFF ------- SRAM Instruction

0x01 0000 0000 - 0x03 000F FFFF ------- L2 cache (associate)
0x01 1000 0000 - 0x03 1FFF FFFF ------- L2 cache (main core only)
0x01 2000 0000 - 0x03 2FFF FFFF ------- L3 cache (main core only)

(oui vous voyez un truc étrange comme SSD RAM , je me demandais si ce n'était pas intéressant d'avoir un SSD comme RAM en plus, celui de la PS5 pouvait atteindre une vitesse de 5-8 Go/s , qui est la vitesse d'une DDR2--1066 ce qui n'est pas rien , ça demande que les programmes soit pensé pour utiliser c'est deux type de mémoire (RAM et SSD) ^^' ).


Et si vous avez des idées d'améliorations n'hésitez pas !
(désolé pour le gros pavé).

ah et vous pouvez voir tout mes brouillons ici :
https://github.com/Kannagi/Altair


J'ai fait le programme assembleur (donc on peut compiler son programme) , il n'y a pas tout (75 instructions sur 120 environ).
Voilà pour la syntaxe : https://github.com/Kannagi/Altair/bl.../vasm/test.asm
Oui le code n'a aucun sens (et faux d'ailleurs ),c'est juste pour vérifier si j'ai les bon opcodes , et que ça compile sans soucis
Il y'a aussi une VM de ma machine en construction (que je tenterai d'émuler le maximun de latence)


Je poste ici , parce que je sais que certain sont calé et donc j'aimerais connaitre toute les contraintes possible
Certain me conseille plus tard de faire ça via un FPGA , mais mon niveau en VHDL est très débutant ,sans parler que je me demande quel FPGA peut émuler 15 millions de transistors sans vendre un rein

Voilà merci de m'avoir lu ^^

[Vincent PETIT]

Je suis impressionné par ton travail. Bravo !

J'espère que quelqu'un pourra donner un avis car moi perso je suis complétement dépassé

[Kannagi]

Je suis impressionné par ton travail. Bravo !

J'espère que quelqu'un pourra donner un avis car moi perso je suis complétement dépassé

Ben merci , j'imagine qu'il est un poil complexe d'où le peu de réponse ah ah

Mais le projet n'est pas mort je vous assure ,je l'avance tout les jours y'a pas mal de nouveauté.
La gestion des posits : https://en.wikipedia.org/wiki/Unum_(number_format)
Donc une alternative aux float et donc à IEEE 754.

J'ai totalement refait l'ISA (vous pouvez la DL ici : )
https://github.com/Kannagi/Altair/bl...chitecture.pdf
Je l'ai pas terminé , il reste les unité de l'AGU (qui permet de gérer les différents cache et transfert).

Et il y'a un début de VM et de documentation (nous sommes trois au final à bosser sur ce projet).

J'ai fait aussi un début de GPU (qui se base sur une partie de l'architecture du CPU ) :
https://github.com/Kannagi/Altair/blob/main/GPU.md
(Et il utile des posits 16 bits).

[electroremy]

Bonjour,

Le hasard fait bien les choses, décidément !

Hier soir, je me suis plongé dans mon livre "Architecture de l'ordinateur" édition 1991, qui parle des débuts de l'informatique pour arriver à ce qui était le must à cet époque : les 80486 et 68040

Aujourd'hui, un article du magazine Elektor m'a fait découvrir ce projet :
http://www.mynor.org/
Un type passionné qui a construit lui même son CPU de A à Z avec des composants électroniques

Et là, ce message sur le forum.

Bref 2020/2021 pour moi, l'année du COVID et des µC (le confinement fut l'occasion pour moi de reprendre un projet 8051 abandonné, puis de me mettre sérieusement à utiliser la plateforme Arduino)

En bas de la page http://www.mynor.org, il y a un "anneau de site", le truc sur Internet utilisé avant les moteurs de recherche...
Cette "anneau" regroupe plein de pages web consacrés aux passionnés qui ont construit eux-même leurs CPU...

Je te souhaite bonne lecture !

Certes, ce sont des "dinosaures pédagogiques", mais avec une approche différente, tu pourrais à partir d'un µC puissant mais "user unfriendly" construire une carte permettant d'émuler ton µC idéal.

A suivre

[Kannagi]

Merci pour les liens ,c'est assez impressionnant , j'adore les vieux processeur (mon preferer reste le 6502 ^^ )
Pour les livres ,le livre de références est Computer Architecture : A Quantitative Approach , il m'a bien aidé personnellement.
Après il y'a de gros site comme :
https://www.realworldtech.com
https://www.anandtech.com

Qui donne des info détaillées dans leur dossiers sur les architectures du moment

[electroremy]

Bonjour

J'adore sous ton avatar la mention "cyber-paléontologue"

Sérieusement, les futurs archéologues auront énormément de mal à retrouver en bon état nos supports de données, et encore plus de mal à comprendre ce qu'on a fait.

Sans indiscrétion, tu as quel âge ?

J'ai 40 ans (génération "Mitterrand" ou plutôt "Club Dorothée"), j'ai commencé en 1993 sur Amiga 1200 avec GFA Basic, puis mon premier PC en 1997 sous Win 95

Je n'ai eu accès à Internet qu'en 1998, et c'était les débuts... auparavant, c'était très difficile et cher d'avoir de la doc, et les logiciels open source étaient encore rares.
Du coup sur Amiga je bricolais avec pas grand chose.

Je me suis vraiment mis sérieusement aux µC assez tardivement, en 2020 (merci le COVID) avec le 89c8051 d'ATMEL puis Arduino (ESP8266, Uno). Je regrette de ne pas l'avoir fait plus tôt, le plus difficile c'est le démarrage, car la bonne nouvelle, c'est que les compétences acquises en programmation sur ordinateur sont très utiles sur µC même si à priori les univers sont très différents.

A bientôt

[gangsoleil]

Hello,

Et si vous avez des idées d'améliorations n'hésitez pas !

Ça fait bien longtemps que je n'ai pas vu cela, et je ne me prononcerai donc absolument pas là-dessus, mais as-tu chercher à contacter des gens dont c'est le métier, je pense notamment à des chercheurs ? L'avantage des labos de recherche, c'est qu'ils sont facilement joignables, et que ce sont généralement des gens curieux et ouverts.

À ta place, je commencerai à regarder:
- les forums spécialisés (dont développez bien sûr)
- Les sites des universités (Paris 7 a un labo d'archi de mémoire)
- Les sites d'Inria et du CNRS pour trouver les équipes qui bossent sur ce genre de choses

[Kannagi]

@ electroremy
Alors la mention "cyber-paléontologue" vient pas de moi , mais d'un membre de ce forum m'a donné parce que je m’intéresse énormément aux vielles machines

Sérieusement, les futurs archéologues auront énormément de mal à retrouver en bon état nos supports de données, et encore plus de mal à comprendre ce qu'on a fait.

Clairement , surtout que pour beaucoup l'histoire de l'informatique c'est Apple/Intel/Windows ^^'

L'Amiga je ne l'ai jamais eu , mais beaucoup entendu parler (et très souvent en bien) , je tente de décortiquer le fonctionnement de pas mal de machine d'où cette mention , je peux te faire partager ce que je sais.

Pour l'Amiga , comme tu le sais il a un blitter (pour ceux qui ne savent pas ,c'est copier des bloc de donnée très utile pour le multimédia), mais ce blitter ne ralenti pas le CPU , ce qui peut être étonnant !
Il y'a pas de VRAM donc le blitter lis/écris sur le même bus que le CPU (un M68k) et la DRAM (je suppose vu sa taille) ne permet pas deux lecture/écriture en même temps , alors comment ils ont fait ?
Ils ont utilisé une particularité du M68000 , les instructions font 4 cycles au minimum , mais l'opcode ne fait que 2 octets sur un bus de 16 bits donc chercher l'opcode ne prend qu'un 1 cycle ,et donc y'a 3 cycles "d’attente" (ou plutôt le processeur exécute mais sans lire la RAM) , et c'est la qu'agi le blitter, pendant ce laps de temps il lit/écris , plutôt ingénieux avec le recul

Quel est le point commun entre une ColecoVision ,le MSX, la Master System et le Texas Instruments TI-99 ?
Ils ont tous le même chip graphique le TMS9918 , d'ailleurs la Master System possèdes des features "caché" (qui ne sont pas indiqué dans la doc officiel de Sega) , ce sont des features du TMS original , qui ne marche que sur certain MS , bien sur la Mega Drive ces features cachés n'existe plus.
Mais si ce chipset m’intéresse autant personnellement ,c'est que toute les consoles/borne d'arcade au japon des années 80 à 92-95 pour la 2D , se base sur ce TMS (dans la logique d'affichage).
Cela semble rien , mais ayant programmé sur toute ces machines(des consoles 8/16 bits et un peu l'arcade), je trouvais cela étrange que même si y'a des différences architectural le fond reste le même , je me suis toujours posé la question si y'a pas eu une machine "original" qui a inspiré toute l'industrie du japon pour le rendu 2D.
Cela n'est peut être pas le TMS (même si Sega et Nintendo le connaissait , donc pour eux , le doute l'est moins) , mais y'a eu peut être eu une machine avec un TMS intermédiaire qui a inspiré les autres et les consoles 16 bits de Nintendo et Sega , bref à creuser donc

De ce que je lis et j'entends il y'a oui une partie de l'informatique (a ces débuts ) de perdu , pour le moment l'histoire de l'informatique intéresse très peu (je parle surtout d'un point de vue technique mais pas que,) mais effectivement dans 100 ans ça sera très complexe d'y comprendre quelque chose parce que toute nos vielles machines ne marcheront plus , et il restera que nos écrit (fait par des amateur/bénévoles pour les machines les moins connus ) ,donc oui il est vital d'écrire,de noter le plus possible maintenant

Bon je m’arrête là , mais voilà pourquoi je met cette mention ah ah

Pour mon age j'ai 32 ans donc plutôt un "jeune" pour quelqu'un qui parle de techno des années 80/90 , mais d'un coté l'informatique est devenu si complexe qu'il me semble impensable de commencer à apprendre le fonctionnement d'un ordinateur avec une machine moderne.
J'ai connu comme toi l'internet des débuts (vers 1998) , mon père l'avait mis sur l'ordi familiale avec AOL , il n'y a avait effectivement pas grand chose sur le net , on ne trouvait pas tout ce qu'on voulait (malheuresement) , maintenant cela à bien changer ah ah


@gangsoleil
Merci pour ce conseils , je n'y ai pas pensé disons que j'ai un peu peur qu'on me prend pour un "fou"
Mais effectivement contacté des chercheurs serai un plus.
J'ai tenté de contacter des personnes qui bosse dans le milieu , mais souvent assez occupé pour répondre à mes questions avec détails

[cr1ptal]

Super intéressant ton topic Kannagi, je te souhaite beaucoup de motivation!
J'ai fait option Systèmes d'Information (Java & co), mais aussi un peu d'ASM Motorolla 68000, un peu d'archi CPU lors du tronc commun et surtout de beaux projets C/C++ (Théorème de Dijkstra, Messages Queues etc). Je ne suis pas en mesure de valider ton schéma, mais ça m'inspire pour mes projets perso (je voudrais arrêter le consulting pour refaire du C/C++).
Il y a peut être un conseil qui me vient à l'esprit: vu le nombre incalculable de failles de sécurité sur les micro processeurs ces 20 dernières années, et qui va en s'accélérant, je pense que pour feindre un progrès en performance, Intel et AMD font des raccourcis au détriment de la sécurité. Il peut être intéressant pour ton modèle de CPU, de ne pas tomber dans cet écueil :^)

[electroremy]

Bonjour,

S'agissant des failles dans les CPU modernes

si certaines sont des bugs, amplifiés par la complexité et les contraintes liées à la compatibilité descendante

d'autres sont volontaires, ce sont des backdoors pour permettre aux polices scientifiques et services secrets d'avoir accès aux données.

S'il est nécessaire d'arrêter les criminels malheureusement ça permet également un flicage des opposants politiques dans les dictatures.

A bientôt

[cr1ptal]

Oui, tout à fait d'accord sur l'aspect back door. Le problème avec cette approche est que c'est à double tranchant. Les ennemis des américains peuvent les exploiter aussi. En 2018, la NSA a du reconfigurer 60.000 serveurs à la suite d'une attaque par malware russe...

[Kannagi]

Si on parle des failles Spectre et Meldown , comme dit juste avant cela est du effectivement à "la complexité et les contraintes liées à la compatibilité descendante".
Comme je n'ai ni l'un , ni l'autre , je n'ai nullement les failles Spectre et Meldown.
C'est failles existe parce les processeurs actuel font des optimisations de façon automatique , et donc qu'on peut tromper ces optimisations pour des failles de sécurité !

Et le processeur que je conçois ne fait aucune optimisation particulière ,pour justement réduire drastiquement le nombre de transistor et simplifié le design , par contre je déplace l'optimisation faite sur le compilo
Donc on peut dire qu'il est sécurisé et performant.
On déplaçant la complexité d'optimisation sur le compilo , cela permet justement d'avoir une fenêtre d'optimisation plus large des instructions exécuté (au lieu de n'avoir qu'une centaine d'instruction comme c'est le cas sur Intel/AMD ).
Mais pour moi , la plus grosse optimisation n'est pas l'IPC , mais clairement l’accès RAM et c'est sur ce point que l'Altair diffère le plus , vu qu'une bonne partie des choix que j'ai fait sont pour résoudre les latences du à la RAM

[electroremy]

On déplaçant la complexité d'optimisation sur le compilo , cela permet justement d'avoir une fenêtre d'optimisation plus large des instructions exécuté (au lieu de n'avoir qu'une centaine d'instruction comme c'est le cas sur Intel/AMD ).

Je suis assez d'accord avec cette approche.

L'inconvénient c'est qu'il faut un compilo spécifique au µC mais on a rien sans rien dans la vie !

J'ai presque terminé un gros projet "embarqué" : une interface homme machine universelle à écran tactile graphique couleur commandé par ethernet, basé sur Arduino.
En fait, cette "interface machine universelle" fonctionne comme un terminal ou un mini navigateur web.

Le projet semblait infaisable au début à cause de la capacité limité en ROM et en RAM de la carte, par rapport à la place occupée par les bibliothèques.

Je me suis rendu compte que les bibliothèques étaient "gourmandes" car elles étaient conçues pour fonctionner avec de nombreux hardware différents.
Malgré les #define et les optimisations du compilateur, qui élimine du binaire les fonctions non utilisées, le code était énorme.

J'ai fait mes propres versions de ces librairies en ne conservant que ce qui était nécessaire pour le hardware que j'ai choisi et mon application.

De plus, j'ai pu optimiser le code pour exploiter au mieux les contraintes et les possibilités du hardware.

Le résultat est là :
- code plus compact
- nombreuses fonctionnalités supplémentaires
- code très rapide (certaines fonctions d'affichages ont été rendues 15 fois plus rapide)

L'inconvénient c'est que mon code ne marche que sur un modèle d'Arduino, un modèle de carte Ethernet et un modèle d'afficheur.
J'ai quand même pris la précaution de basé mon projet sur du hardware très répandu (Arduino UNO, Shield Ethernet 2 officiel, afficheur ILI9341 avec dalle tactile XR2046)

D'autre part mon code est bien plus court que les bibliothèques initiales, et donc facile à "forker" pour un autre hardware.

La solution que j'ai choisie se rapproche du monde des consoles de jeu vidéo : toutes les consoles de jeu sont identiques, et donc les développeurs peuvent exploiter le hardware au maximum, contrairement aux ordinateurs types PC où les combinaisons de hardware sont infinies et donc les développeurs sont obligés de faire du code "compatible" au détriment de la performance.

Voilà pourquoi, dans les années 1990, un modeste Amiga 500 arrivait à faire tourner de super jeux vidéo qui donnait du fil à retordre à des PC plus rapides et avec plus de mémoire.

Il y avait très peu d'Amiga différents (au début des années 1990 : le 500, le 1000, le 600 et le 1200), donc les développeurs pouvait les exploiter à fond sans devoir faire de nombreuses versions différentes.

Le problème qu'on a dans le monde de l'embarqué, c'est que les fabricants ont multiplié les cartes, et les développeurs de librairies se retrouvent obligés de faire des codes capables de fonctionner avec des milliers de combinaisons de hardware possible. Selon le principe du "plus petit dénominateur commun", ces librairies utilisent des fonctions dont on est sûr qu'elles fonctionnent partout au détriment de la rapidité et de l'occupation mémoire. C'est complétement stupide de vouloir programmer de l'embarqué de la même façon que les PC.

On en arrive à avoir des gens qui me disent "laisse tomber Arduino, prend un Raspberry PI", c'est du gâchis, et il y a d'autres problèmes car un Raspberry PI est un ordinateur ce qui occasionne des contraintes qu'une carte à microcontroleur ne possède pas :
- alimentation en 5V précise (un Arduino accepte 7V à 12V, ce qui permet de déporter l'alimentation)
- temps de démarrage très long (ma carte est prête en moins de 2 secondes, en retirant le bootloader je peux être encore plus rapide)
- obligation de faire une extinction "propre" (comme le démarrer -> arrêter de Windows)
- vulnérabilité aux virus informatiques (dans un Arduino le code est en ROM, c'est impiratable, à la limite en fonction de l'application un pirate qui accède au réseau local sur lequel est branché mon interface pourrait planter la carte )

Sur les logiciels qui tournent sur nos ordinateurs actuels, le ratio entre la puissance du hardware et la capacité de calcul est mauvais, comparé à ce qu'un bon programmeur peut faire en embarqué ou sur console de jeu.

Ce n'est pas anondin. On gaspille du matériel et de l'électricité.

Par rapport au début de l'informatique, on a des ordinateurs avec 1000000 de fois plus de mémoire et 1000 plus rapide mais on doit faire à peine 100 fois plus de choses avec.

Raz le bol de voir que le moindre logiciel occupe des centaines de Mo voire plusieurs Go

J'ai créé un émulateur pour PC pour mon "interface homme machine universelle".
Le fichier executable ne fait que quelques dizaines de ko, et l'occupation mémoire est ridicule.
C'est normal, j'ai simplement "porté" mon code c++ arduino en .NET

Cet émulateur, qui une sorte de mini navigateur web utilise infiniment moins de ressources qu'un onglet de Chrome ou Edge.
Et cerise sur le gâteau, cet émulateur est rapide, alors que tout est dessiné pixel par pixel !
L'envoi de la requête au serveur, la réception de la réponse, les calculs, le dessin de l'écran de 240 x 320 pixels dure au total à peine plus de 100 ms.

Du coup, si à l'origine de mon projet je voulais que mon serveur Arduino soit capable de générer des pages web pour être pilotable aussi par un ordinateur, je pense que je vais plutôt utiliser cet émulateur comme logiciel de commande.

Bref, en informatique, il faudrait revenir à l'essentiel, arrêter de renouveler le matériel en permanence, faire simple et efficace, avec du code optimisé.

Un PC soi-disant "dépassé" pourrait faire des merveilles si les logiciels exploitait son hardware à fond.

A bientôt

[Kannagi]

Effectivement ton approche est bonne , et ton optimisation est clairement celle qu'on fait sur console donc qu'on optimise pour un hardware dédié.
On fait trop généraliste du coup toute les performances tombe ,c'est dommage de vouloir éloigné le programmeur a ce point de la machine ,je pense qu'il faut un juste milieu.

Mais oui dommage aussi de lire ou d'entendre qu'un Arduino n'est pas assez puissant , moi je trouve ça incroyablement puissant

Je suis assez d'accord avec cette approche.

L'inconvénient c'est qu'il faut un compilo spécifique au µC mais on a rien sans rien dans la vie !

Exact , on a rien sans rien , mais c'est pas pour un µC mais plus pour un futur Amiga

Sur les logiciels qui tournent sur nos ordinateurs actuels, le ratio entre la puissance du hardware et la capacité de calcul est mauvais, comparé à ce qu'un bon programmeur peut faire en embarqué ou sur console de jeu.

Clairement que la ratio est vraiment mauvaise sur PC

Bref, en informatique, il faudrait revenir à l'essentiel, arrêter de renouveler le matériel en permanence, faire simple et efficace, avec du code optimisé.

Un PC soi-disant "dépassé" pourrait faire des merveilles si les logiciels exploitait son hardware à fond.

Mais je suis pour qu'on revient comme avant ,avoir un modèle d'ordinateur , et peut être l'évolué tout les 5-7 ans !
Bien sur sans le X86
Lui c'est vraiment un proc qui aurait du rejoindre le cimeterre en même temps que le M68000 !

[cr1ptal]

@electroremy:
Je suis d'accord avec toi, écrire du code d'huitre compensé par des machines monstrueuses, c'est lamentable. Si l'évolution, façon de parler, a pris de telles tournures, c'est à cause des pressions de la rentabilité commerciale. Dans les années 90, on ne pouvait pas s'imaginer sortir un jeu complètement buggué et se dire, c'est pas grave, on fait une mise à jour de 10GB day one et on est gagnant financièrement. Ce schéma, de l’appauvrissement du savoir faire général, est vrai dans presque tous les domaines aujourd'hui, la pression financière écrase tout en cascade.

[electroremy]

Vos réponses me rassurent, je ne suis pas le seul à penser ça...

J'ai toujours gardé mes ordinateurs longtemps

J'avais du vendre mon Amiga 1200 au bout de 4 ans pour aider au financement de mon premier PC

Le premier PC, acheté en 1997 : Cyrix 166+ 16Mo de RAM, CM avec des ports PCI et ISA (le must pour utiliser de vielles cartes), Windows 95 OSR 2 remplacé par Windows 98 qui plantait moins. J'ai du changer le disque dur.
J'ai toujours ce premier PC, il me sert pour les logiciels anciens (MS DOS, Win 3.11, Win 95) qui utilisent de vielles interfaces (typiquement le port parallèle)

Mon deuxième PC : Amd Athlon XP, 256Mo de RAM, sous Windows XP, acheté en 2000, gardé 10 ans (j'ai du changer le disque dur)
J'avais "tunné" la tour pour la rendre silencieuse tout en améliorant le refroidissement
Il a rendu l'âme (carte mère HS)

Mon PC actuel : une belle bête de course acheté en 2010, config haut de gamme avec tour Antec, 16 Go de RAM Corsair, Intel core I7, carte graphique haut de gamme, deux disques dur mécaniques + un SSD pour le système, deux bons écrans 24 pouces Samsung, ce PC a été acheté pour faire de la photo, de la vidéo et de la CAO.

Ce PC est toujours dans la course.
Deux barrettes de RAM avaient lâché il y a un an et demi, elles étaient garanties 10 ans et j'ai fait joué cette garantie, j'ai obtenu deux nouvelles barrettes.
J'avais aussi du remplacer un disque dur.
On ne regrette jamais d'avoir choisi la qualité.

Ce PC tourne sous Windows 7 Ultimate 64 bits, je continue à recevoir les mises à jour de Microsoft.

Je ne suis pas pressé de changer cet ordinateur :
- parce que les ordinateurs actuels ne sont pas vraiment plus puissants
- parce qu'il convient parfaitement à mes besoins
- parce que je déteste Windows 10 qui équipe le PC portable de mon travail
- parce que je déteste la mode des logiciels "en location", vu le nombre d'années que je garde mes PC, les licences "définitives" sont nettement plus intéressantes.

J'ai aussi une "antiquité" : un PC "transportable" Toshiba T3100, c'est un 80286 avec 640ko de RAM (comme disait Bill Gates à l'époque personne n'aura besoin de plus que ça), un écran monochrome noir et orange, un disque dur de 10Mo et un lecteur de disquettes basse densité.
C'est un PC portable mais sans batterie, il faut le brancher à une prise de courant avec un gros cordon pour électroménager (2P + terre) il fait 6 cm d'épaisseur et pèse son poids
Il tourne sous MS DOS 3, mais il gère parfaitement les dates : pas de bug de l'an 2000, d'ailleurs MS DOS utilise la date pour me dire "Your version of MS DOS is too rather old"
A ce niveau d'obsolescence la machine n'est tout simplement plus assez moderne pour être contaminé par les virus actuels (quoi ? pas de javascript ?)
MS DOS est fournit avec une sorte de menu graphique à la Norton Commander, la machine est vraiment facile à utiliser.
Utilisé pour faire de la programmation en BASIC et aussi avec la première version de Borland Turbo C++ en abandonware.
Les 10Mo du disque dur sont largement suffisants.
Le disque dur fait un bruit de disqueuse et on entend bien les aller retour des têtes de lecture.

La carte mère est faite avec de vieux composants "traversants", la machine peut se réparer comme un ampli hifi des années 70/80

A bientôt

[Kannagi]

J'ai pas mal avancé sur mon projet ,par contre j'aurais des questions , vu que admettons qu'on veut refaire un RasPi , c'est "facilement" faisable ?
(facilement dans le sens où c'est pas un capacité ultra rare de trouver des ingénieurs faire ce genre de PCB et trouver les bons composants ).
Et je suis curieux de savoir combien coûte un PCB (+ composant) dans le genre ^^

Pour mon projet , j'ai terminé complémentent l'ISA du CPU et GPU (a quelque détails près) et j'avance sur la partie VHDL :p
J'ai décidé des caches que j'allais utilisé , des I/O (très inspiré du RasPi forcément ) etc etc , bref les specs ont bien été choisis.

Donc ma vision , reste de faire un RasPi un peu plus évolué , je vois le truc comme ceci :

Main core : RISC-V 2.5 GHz or Altair K1 2.5 GHz
Sub core : Altair K1 2.5 GHz , 6 cores
LPDDR4 2666/3200 MHz , 8GB in a unified memory
GPU Aldebaran G1 1 GHz , 4 CU , 1 TFlops

Le Die :


Et niveau connectique :
-4 USB
-1 SD
-1 sorite HDMI (+1 VGA ? )
-1 mini pci
-1 Ethenet
-1 port jack
-SATA

Voilà voila (bon comme ça , ça fait court mais j'ai passé pas mal de temps sur le CPU/GPU et sur l'architecture globale de ces deux parties ).

[Auteur]

J'ai aussi une "antiquité" : un PC "transportable" Toshiba T3100, c'est un 80286 avec 640ko de RAM (comme disait Bill Gates à l'époque personne n'aura besoin de plus que ça), un écran monochrome noir et orange, un disque dur de 10Mo et un lecteur de disquettes basse densité.

tiens ça me fait penser à un portable avec lequel j'ai travaillé (stage dans un labo) il y a.... 25 ans Je programmais en Basic et Turbo Pascal. Et compte-tenu de la RAM et du disque dur, tu avais intérêt à bien optimiser ton code.


Je ne me prononcerai par sur le projet de Kannagi, ça me dépasse complètement. Et pour rechercher des articles scientifiques dans ce domaine, je ne sais pas quels mots-clef utiliser.
Mais peut-être devrais-tu effectivement regarder dans un premier temps les FPGA et du côté des SBC.

[Kannagi]

La prog à l'ancienne devrait être remis au goût du jour pour apprendre au moins au programmeur quelque technique pour économiser de la RAM/Temps CPU

Je ne me prononcerai par sur le projet de Kannagi, ça me dépasse complètement. Et pour rechercher des articles scientifiques dans ce domaine, je ne sais pas quels mots-clef utiliser.
Mais peut-être devrais-tu effectivement regarder dans un premier temps les FPGA et du côté des SBC.

Je travaille avec un FPGA (enfin pas moi ), mais quelqu'un d'autre qui trouvé le projet intéressant (et qui bosse chez intel :p ).
Mon niveau en VHDL est bien trop insuffisant pour faire certaine partie ^^'