Discussion :

[nono17pero]

Ah ouais bonne idée !

J'ai justement fini l'algorithme du processeur 7001, du premier prototype. Il fait des additions, des adressages, 4 types de comparaisons et des sauts conditionnels.

Pour répondre à Golden Boy, les registres ne sont pas vraiment un avantage. Leur problème est déjà la taille, mais ils sont souvent trop rapides par apport au reste de l'ordinateur, ce qui ne rend pas beaucoup...
Et justement, le but de la eSAC est d'être beaucoup plus simple que toutes les autres architectures, donc moins cher. En commençant par supprimer les registres...

[Forthman]

Ok...
Je sens que tu vas nous dire que ton proto sera réalisé à partir
de circuits logiques TTL de la série 74LS

a+ François

[nono17pero]

Peut-être ...

[golden boy]

D'un autre côté, peut-être que de se passer des registres faciliterait la programmation ASM, mais je suis bien curieux de voir ce qu'il en sera.
Ah, et bien le merci d'avoir rédiger la description de l'algorithme en Français

Et si tu ne sais pas faire les soustractions binaires, pourquoi ne pas prendre un circuit qui gère ça déjà existant (c'est peut-être un peu chère par contre) ?

[edfed]

Les CPU X86 sont prototypés avec des fpga.

l'interet des registres est d'accelerer certains calculs n'aillant pas besoin d'acceder à la ram.

il est plus rapide de faire:

add reg,reg

que

add [mem],[mem]

par exemple.

les acces à la ram sont lents, c'est comme ça.

à moins d'avoir un coeur d'execution plus lent que la RAM, il n'y à pas d'interet à supprimer les registres.

les registres permettent ce que la ram ne peut pas permettre, travailler au plus pret possible de l'alu.

entre un cycle d'addition sur registre qui prend un demi cycle, et une opération sur la ram qui en prend au minimum 2, il y a déjà une difference de 4. et là, on considère que la ram est aussi rapide que le CPU.

sinon, une solution viable, et pas mal du tout, ça serait de prendre la famille X86, reduire son jeu d'instructions, integrer la ram (au moins 1 Mo), la rom (flash au moins 4Go) et les peripheriques sur la puce, et là, on aura un CPU bien.
faire la carte mère, définir un protocole de programmation de la puce, jtag ou icsp ou autre...

et rendre la techno assez interressante pour qu'elle puisse remplacer les produits déja utilisés.
non, franchement, c'est pas possible, il vau mieu concentrer son energie sur autre chose, comme par exemple, devenir codeur d'elite, ce qui ne depend d'aucune architecture et ouvre peut etre des portes.

mais même là, les codeurs d'elite sont pas pris au serieux, car ils sont pas assez standardisés. les entreprises preferent les gens capables d'etre d'accord avec le boss même s'ils trouvent que le boss est un BIP qui à tord.

donc, avis au collegien, si tu as la chance d'avoir acces à un PC et l'envie de coder, oublie la eSAC et apprend à coder comme un expert, ça te servira plus tard pour gagner ta croute, et financer tes prototypes.

[Obsidian]

Alors je sais qu'il y a plus passionnant et plus facile que la logique séquentielle, mais je pense que tu passes à côté d'une chose essentielle là : ça me parrait bizarre de devoir opérer sur des valeurs directement dans une mémoire RAM :o

C'est une question de point de vue : certains micro-contrôleurs embarquent leur propre RAM. À ce moment, cette mémoire — généralement très limitée (comprendre : atteint difficilement le kilo-octet) — est gérée sur la même puce. On peut donc directement câbler des entrées-sorties sur certains octets de cette « RAM » et dans le cas des PIC12xxxx, par exemple, l'instruction RISC tient sur un mot de douze bits qui embarque systématiquement une adresse. Dans une telle architecture, les notions de mémoire RAM et de registres du processeur en particulier se confondent. Mais c'est un cas très particulier.

J'ai justement fini l'algorithme du processeur 7001, du premier prototype. Il fait des additions, des adressages, 4 types de comparaisons et des sauts conditionnels.

Le fait que ton micro-processeur soit décrit par un « algorithme » me gène un peu (à ce stade, en tout cas). L'algorithme en question est censé être mis en œuvre par un programme, celui-là même que ton micro-processeur, lui, est chargé d'exécuter.

Pour répondre à Golden Boy, les registres ne sont pas vraiment un avantage. Leur problème est déjà la taille, mais ils sont souvent trop rapides par apport au reste de l'ordinateur, ce qui ne rend pas beaucoup... Et justement, le but de la eSAC est d'être beaucoup plus simple que toutes les autres architectures, donc moins cher. En commençant par supprimer les registres...

C'est parce que tu n'as pas compris ce qu'ils sont ni à quoi ils servent. Question bête : quel dispositif ton micro-processeur va-t-il utiliser pour copier une valeur d'une case mémoire vers une autre ?

Je sens que tu vas nous dire que ton proto sera réalisé à partir de circuits logiques TTL de la série 74LS

À son âge, faire quelque chose qui marche avec des 74xx, ce serait déjà remarquable.

[nono17pero]

Ben, en fait les registres sont exactement la même chose que la RAM, sauf qu'ils sont beaucoup plus petits ; normal, il sont dans le microprocesseur !
Mais l'avantage de supprimer les registres est d'abord la simplicité, mais surtout le prix. Le prix du processeur sera beaucoup moins grand.
De plus, l'accès à la RAM est plus facile au niveau technique.

Et, c'est vrai que j'ai pensé à un moment réutiliser les anciennes instructions, mais le problème est qu'on ne peut pas les raccourcir plus. Toujours à cause des pointeurs ! Si on veut avoir plus de 256 Ko de RAM, on est obligé de les noter sur plus d'un octet.
Et ça simplifie le code !

[golden boy]

Pour le prix des registres, je suis d'accord ; mais veux-tu faire des processeurs (pouvant concurrencer ARM et exploiter le même marché) ou veux-tu faire des micro-contrôleurs pour machines à café ?


L'explication sur les PIC12xxxx d'Obsidian me rend moins septique, mais autre chose me gêne quand même : les pointeurs classiques qu'on retrouve un peu partout (*IP, *SP ...) seront alors contenus dans la mémoire RAM, ou alors tu veux aussi te passer des pointeurs (ce que j'ai beaucoup de mal à imaginer) ?

Je ne pense vraiment pas qu'il soit bon de se passer d'un élément essentiel juste pour contourner un obstacle de difficulté. Si tu rencontres justement ce genre d'obstacle, c'est que tu as encore besoin d'apprendre avant de concevoir.

[nono17pero]

Non, justement, il y a toujours besoin de pointeurs ! Puisqu'il n'y a plu que de la RAM !

La eSAC se limite vraiment à ce que l'on peut faire de plus simple, pour que ce soit moins chère, plus résistant, plus d'autonomie pour la batterie aussi, mais surtout, pour que tout le monde puisse programmer son propre OS !

[Obsidian]

Non, justement, il y a toujours besoin de pointeurs ! Puisqu'il n'y a plu que de la RAM !

N'empêche que tu n'as toujours pas répondu à ma question : comment t'y prends-tu techniquement pour copier une case mémoire vers une autre ?

[nono17pero]

Ah oui pardon !

En fait, c'est très simple. Le processeur ouvre la première variable, ouvre la deuxième, lit la première, et dirige les signaux vers l'autre variable, puis il ferme toutes les variables. C'est le principe de l'instruction MOV.

[Obsidian]

En fait, c'est très simple. Le processeur ouvre la première variable, ouvre la deuxième, lit la première, et dirige les signaux vers l'autre variable, puis il ferme toutes les variables.

Et — techniquement — comment ton micro-processeur miracle va-t-il s'y prendre pour « ouvrir » ces variables et « diriger » les signaux de l'une vers l'autre ? Ce n'est pas un détail technique que l'on résout en bout de chaîne une fois que le principe général a été établi, c'est le fondement même du fonctionnement de ton circuit.

C'est le principe de l'instruction MOV.

Non, ce n'est pas le principe de l'instruction MOV, qui elle-même n'est pas une seule et même instruction mais une série de code-opérations différents selon le mouvement à effectuer, même en faisant abstraction du mode d'adressage. Sur d'autres architecture, notamment les 68xx, ces codes sont associés à des mnémoniques distincts tels que LDx (Load) pour lire une valeur depuis la mémoire et STx (Store) pour faire le chemin inverse.

Il n'y a pas « d'ouverture » ou de « fermeture » des variables. On n'est pas en train de parler de gestion de fichier.

Il faut absolument que tu apprennes, par toi-même ou via un cours, comment fonctionne un micro-processeur actuel avant de vouloir en concevoir un.

[golden boy]

Une question : connais-tu les rudiments de la logique booléenne ? Connais-tu les concepts de la logique combinatoire et de la logique séquentielle ?

Je pense que là sont, entre autres (il y a sûrement plein d'autre trucs), les principales connaissances à avoir pour concevoir un processeur. Rassure-moi, dis-moi que tu connais tout ça (si c'est le cas, chapeau bas, pour un collégien).

Pour l'étude d'un processeur, ce n'est pas une mauvaise idée, mais évite quand même d'étudier en premier temps le tout dernier hexacores ultra sophistiqué de cette année, prends plutôt un vieux Z80 ou un 68k et augmente la difficulté peu à peu.

[Obsidian]

Pour l'étude d'un processeur, ce n'est pas une mauvaise idée, mais évite quand même d'étudier en premier temps le tout dernier hexacores ultra sophistiqué de cette année, prends plutôt un vieux Z80 ou un 68k et augmente la difficulté peu à peu.

Voire même un 6809. Je suis vraiment fan de ce processeur. C'était celui de la gamme Thomson, mais il a été également utilisé dans de nombreux cours, notamment ceux de l'éducation nationale en F2, et dans plusieurs platines de simulation.

Je le trouve ni trop compliqué, ni trop simple, l'orthogonalité est bonne, et les instructions comme les modes d'adressages sont bien conçus. En plus, la « dualité » des principaux registres (deux accus ALU A et B, deux registres d'index X et Y et deux pointeurs de pile S et U, ce qui n'est pas courant) permet de faire facilement beaucoup de conversion, tout en obligeant à en faire un usage raisonné (on ne se retrouve pas d'emblée avec 16 registres multi-usages).

Je me suis globalement bien amusé avec tous les processeurs que j'ai pu avoir entre les mains (PIC12xx, PIC16xx, 6809, Z80, 68000, x86, Saturn HP…) mais c'est avec celui-ci que j'ai pris le plus de plaisir, je crois.

[edfed]

+ 6809 pour le 6809, il est très interressant de commencer par ce processeur, quitte à passer par la suite sur d'autres, dont les X86 qui sont l'une des famille de CPU les plus avancés pour le moment.

si par contre, niveau moyens tu es limité, prefere utiliser un microcontroleur dont la mise en oeuvre ne coute pas des masses, comme un pic par exemple, ou un 68HC11 ou 12, car ces derniers ont un coeur 6809, et des peripheriques type 6820, 6821, integrés, des sortes de microPC, sur un seul composant.

celà dit, le pic ne t'apprendra pas grand chose, car le jeu d'instruciton est vraiment reduit, et il faut une serieuse experience de l'assembleur pour comprendre comment faire sur un pic ce que font les CPU plus avancés, comme par exemple, les divisions, les multiplications, les declalages arythmétiques, etc...

l'assembleur, ce n'est vraiment qu'une petite partie de l'univers des CPU, c'est la partie que l'on pense en dernier, car avant elle, il y a le code machine, comment encoder les instructions. et avant ça encore, il y a les concept très bas niveau, l'electricité, l'electronique, logique, mecanique, architecture...

je pense qu'un amateur ne peu pas concevoir de CPU, impossibilité technique et competences limitées.
même un expert en assembleur est incapable de ça, car il y a d'autres domaines à maitriser, la chimie, l'electronique, la physique pure et dure, toutes ces choses que l'on ne soupconne pas lorsque l'on code notre premier hello world en QBASIC.

ouverture et fermeture de variable, ceci est un non sens pur et dur issu des languages de haut niveau.

en bas niveau, quelle que soit l'instruction, il y a lecture ou écriture ou les deux, point barre, exit l'ouverture et la fermeture, les données ne sont pas des fichiers, les fichiers font intervenir des concepts haut niveau (ne pas comprendre mieu, mais juste, plus haut dans l'arbre des dependances).

les premiers processeurs etaient faits avec des caillous et des batons, sur des sols poussiereux de la grece antique. ça à donné les maths que l'on connais, et le besoin d'une machine car les maths ont vite montré nos propres limites humaines.

[Obsidian]

je pense qu'un amateur ne peu pas concevoir de CPU, impossibilité technique et competences limitées. même un expert en assembleur est incapable de ça, car il y a d'autres domaines à maitriser, la chimie, l'electronique, la physique pure et dure, toutes ces choses que l'on ne soupconne pas lorsque l'on code notre premier hello world en QBASIC.

Ce n'est pas tout-à-fait vrai. Certes, il faut avoir beaucoup de cordes à son arc pour développer une puce qui ait sa place sur le marché actuel, et être un industriel aguerri pour la produire. Par contre, concevoir en soi un micro-processeur modeste est à la portée d'un amateur éclairé, pour peu qu'il ait la fibre et qu'il soit sûr de bien comprendre de quoi il parle.

Il est possible de mettre au point une architecture virtuelle que l'on concrétise ensuite avec des circuits logiques a priori, mais ça peut être aussi des morceaux de bois et un moteur électrique, des briques de Lego, ou même un simulateur sur un ordinateur existant, lequel simulateur peut d'ailleurs prendre des formes assez inattendues. Le meilleur exemple est cette implémentation d'un CPU 8 bits avec Minecraft :

[ame="http://www.youtube.com/watch?v=yxAmphwLPDY"]CPU 8 bits avec Minecraft[/ame].

[golden boy]

Oui, virtuellement, mais physiquement, comme --1-- le rappelle (et je suis d'accord), on a aussi de la chimie, sûrement pour la lithogravure en silicium, à connaître ; je suppose que même un CPU modeste n'a pas de fils en cuivre.
En physique, il faut savoir ce qu'est le TDP et connaître tout plein de formules, notamment sur l'effet Joule (problématique principale de la conception de processeur à ce jour) et la dissipation de l'énergie thermique (cela fut mon sujet de TPE, et les formules pour calculer l'énergie dissipée n'étaient pas belles à voir, ça va jusqu'à l'intégrale, donc supposons aussi des notions en analyse pour notre concepteur de CPU qui est au collège).
De plus, un professeur de SI m'avait aussi parlé de dopage d'atomes et de supraconductivité, là, on touche la physique de très haut niveau (bien que ces deux dernier points peuvent être ignorés pour un CPU "modeste").

Et tout ça, même le meilleur programmeur ASM du monde n'a pas besoin de le savoir, c'est au concepteur lui-même de le savoir.

Et il faut gérer tout ça, car un CPU réel, ça peut griller (ça serait bête de voir son prototype, fraîchement sorti de la fonderie, mort juste à cause d'un mauvais calcul ou d'un manque de connaissance en d'autre domaine que la logique et l'électronique) !

Mais heureusement, tout ça s'apprend hein (mais post-bac).

[nono17pero]

Pfiouh pas tout le monde en même temps SVP, je ne m'y retrouve plu !

Alors. Tout premièrement. Il me semble qu'il y avait une question rapportant à la technique qu'utilise le processeur eSAC pour copier une variable. Ah oui, alors c'est effectivement très simple, mais moins du point de vu électronique.
Le processeur ne lit pas les variables pour de vrai, c'est juste qu'il attend que les signaux viennent a lui. Comme quand il exécute un programme : il ne va pas chercher le programme, c'est le programme qui vient à lui.
Pour les variables, c'est pareil, sauf qu'il oriente la source du programme vers où l'on a demandé de lire la variable ; c'est ainsi qu'il peut la "lire" et que l'on peut ensuite en faire ce que l'on veut.

Pour répondre à Golden Boy, il est ÉVIDENT que je connais les principes de la logique booléenne : qui peut vivre savoir quel est son fonctionnement le plus simple ? La logique booléenne est évidemment impliqué dans les ordinateurs de type eSAC, je me suis donc suffisamment renseigné. Je crois .

En réponse à toutes les questions sur les processeurs, du moins les suggestions, que je lit attentivement et dont je gratifie les auteurs ( ), je ne vais pas utiliser de processeur en soit. Enfin, si, bien sur, la dessus réside le fait qu'un ordinateur est un ordinateur.
Mais c'est absolument inutile de connaître le nom de tous les registres par coeur dans la mesure où ce que je fait, c'est un peu la réinvention de l'ordinateur ; mais je suis une autre route, celle des instructions à 5 octets.
J'ai bien sur appris beaucoup de choses en informatique, grâce à beaucoup de gens très amicaux comme vous tous, mais je conçois un ordinateur comme si c'était le premier. A partir de l'idée des ampoules allumées et éteintes.

[Forthman]

Dans un tout petit 6809 il y a déjà pas moins de 40000 transistors
Faut être patient pour souder tout ça

[Obsidian]

Le processeur ne lit pas les variables pour de vrai, c'est juste qu'il attend que les signaux viennent a lui.

Ça ne veut toujours rien dire.

Comme quand il exécute un programme : il ne va pas chercher le programme, c'est le programme qui vient à lui.

Non, le programme ne « vient » pas au processeur. Ce n'est pas une entité autonome. C'est une suite de directives qui sont consignées quelque part (en RAM) et c'est au processeur qu'il appartient de lire cette mémoire et d'agir en fonction de ce qu'il y trouve.

Pour les variables, c'est pareil, sauf qu'il oriente la source du programme vers où l'on a demandé de lire la variable ; c'est ainsi qu'il peut la "lire" et que l'on peut ensuite en faire ce que l'on veut.

Ça ne veut toujours rien dire. Écoute, il n'y a pas de honte à être profane, mais n'essaie pas d'inventer des réponses si tu ne les connais pas.

Ce que je voulais te dire, donc, c'est qu'en soi, un micro-processeur utilise en parallèle :

— Un bus de données, bidirectionnel, qui lui permet de lire une donnée depuis un composant externe où d'aller l'y écrire ;
— Un bus d'adresses, qui permet au processeur de dire avec qui il veut dialoguer ;
— Un bus de contrôle, qui est formé de lignes indépendantes entre elles, à commencer par R-/W qui permet au processeur de dire s'il veut lire ou écrire à la position indiquée sur le bus d'adresse.

Donc, quand le processeur veut copier le contenu d'une case vers une autre, il doit :

• Afficher l'adresse de la case source sur le bus d'adresse ;
• Lire ce qu'il y voit ;
• Retenir cette valeur ;
• Afficher l'adresse de la case destination sur le même bus d'adresse ;
• Transférer la valeur retenue vers cette destination.

Étant donné que source et destination partagent le même bus, il est évident que le processeur doit procéder en deux étapes, et retenir la valeur entre les deux. Pour cela, il lui faut une toute petite zone de mémoire interne correspondant à la largeur du bus de données. Et cette petite zone de mémoire s'appelle… un registre !

D'une manière plus générale, un « registre » en informatique, c'est n'importe quoi qui puisse contenir une valeur, et ce bien que la plupart des gens associent le mot « registre » aux « registres du processeur » en particulier. Cette dernière locution est d'ailleurs un abus de langage d'une certaine manière, car elle est trop vague.

Ça signifie en tout cas que ta nouvelle architecture ne va pas du tout se passer de registres, comme tu le penses, mais simplement en masquer l'utilisation aux yeux du programmeur, ce qui n'est pas du tout une bonne chose.

Si c'est une instruction MOV [adressesource],[adressedestination] que tu veux faire, alors non seulement ce n'est pas plus simple, mais les programmeurs assembleur risquent de t'en vouloir. Mais surtout, c'est déjà faisable en l'état en définissant les bonnes macros dans ton code assembleur. À ce stade, donc, on peut dire que l'on s'éloigne de l'assembleur pour se rapprocher des langages de haut niveau, ce qui est l'anti-thèse de ce que tu cherches à faire au départ.