Très propre?
Minimaliste plutôt: un mauvais clone du MIPS.. Et ça je trouve que c'est un problème: on est au 21ème siècle, les ordinateurs sont supposés être connecté à Internet, ce qui devrait se refléter dans le CPU.
Le problème c'est qu'ajouter de la "vrai" sécurité dans le CPU (isolation mémoire), c'est très coûteux, sauf qu'il y a quand même quelques fonctionnalités de sécurité light/par cher qui existent mais le RISC-V ne les implémentent pas (à mon avis car ils ont tout misé sur la faible consommation en énergie pour concurrencer ARM) et ça j'ai du mal a l'avaler.
Plus concrètement:
-Pas de détection des débordement entier. La version originale du MIPS avait pour chaque opération entière une variante qui déclenchait un TRAP en cas de débordement entier.
Être sûr que X+1 est supérieur à X ou bien que ton programme se plante gratuitement(1), personnellement j'adore (c'est compatible avec la sémantique du C/C++ et au niveau implémentation hardware c'est quasiment gratuit, le plus gros problème est que ça occupe un bit supplémentaire dans l'encodage des instructions).
-Faciliter les calculs avec des entiers long: avec un CCR, on peut faire des calculs entiers longs efficacement, calculs long qui sont très utile pour le chiffrement.
Le chiffrement c'est plutôt utile a l'heure actuelle non?
Mais le RISC-V n'a ni variante d'instructions avec TRAP, ni CCR..
Désolé mais un Mill d'un point de vue technique, ça me fait plus saliver qu'un RISC-V (même s'ils déposent des brevets pour leur design et que je doute de leur succès).
1: Avec juste un CCR et un compilateur ajoutant dans 'branch on overflow', l’histoire a montré que comme cela ralentit le code 'normal' (même si c'est très faible) ce ne sera pas très utilisé..
[^] # Re: Pas si sûr que ça intéresse vraiment
Posté par reno . En réponse à la dépêche Librem 13, l’espoir d’avoir un jour un ordinateur libre. Évalué à 9.
Très propre?
Minimaliste plutôt: un mauvais clone du MIPS.. Et ça je trouve que c'est un problème: on est au 21ème siècle, les ordinateurs sont supposés être connecté à Internet, ce qui devrait se refléter dans le CPU.
Le problème c'est qu'ajouter de la "vrai" sécurité dans le CPU (isolation mémoire), c'est très coûteux, sauf qu'il y a quand même quelques fonctionnalités de sécurité light/par cher qui existent mais le RISC-V ne les implémentent pas (à mon avis car ils ont tout misé sur la faible consommation en énergie pour concurrencer ARM) et ça j'ai du mal a l'avaler.
Plus concrètement:
-Pas de détection des débordement entier. La version originale du MIPS avait pour chaque opération entière une variante qui déclenchait un TRAP en cas de débordement entier.
Être sûr que X+1 est supérieur à X ou bien que ton programme se plante gratuitement(1), personnellement j'adore (c'est compatible avec la sémantique du C/C++ et au niveau implémentation hardware c'est quasiment gratuit, le plus gros problème est que ça occupe un bit supplémentaire dans l'encodage des instructions).
-Faciliter les calculs avec des entiers long: avec un CCR, on peut faire des calculs entiers longs efficacement, calculs long qui sont très utile pour le chiffrement.
Le chiffrement c'est plutôt utile a l'heure actuelle non?
Mais le RISC-V n'a ni variante d'instructions avec TRAP, ni CCR..
Désolé mais un Mill d'un point de vue technique, ça me fait plus saliver qu'un RISC-V (même s'ils déposent des brevets pour leur design et que je doute de leur succès).
1: Avec juste un CCR et un compilateur ajoutant dans 'branch on overflow', l’histoire a montré que comme cela ralentit le code 'normal' (même si c'est très faible) ce ne sera pas très utilisé..
CCR: Condition Code Register