Nos langages bas niveaux sont trop loin du bas niveau, et parfois je me dis qu'il faut raser Carthages et revenir à des bases solides : LE HARDWARE.
Moi, j'ai grandi en micro-électronique avec des oscilloscopes et un bit d'un registre il a plus que 2 valeurs parmi 0 et 1. Il en a infiniment plus, mais, en synthèse et conception de circuit électronique, le comité IEEE s'est arrêté à 9 valeurs distinctes repérables.
Vous savez pourquoi on ne laisse pas les développeurs accéder aux 9 états ?
Car certains états sont littérallement des courts circuits...
Si bien, que pour protéger le HARDWARE du développeur on a crée des niveaux d'executions surperviseurs ou au lieu d'accéder aux endroits dangereux on donnait des macros aux codeurs pour faire du kikoo lol. Genre le printf de "hello world".
Le truc qui imprime à l'écran c'est la limite que l'on te donne au hardware pour que tu ne fasses pas (comme moi) cramer ton écran.
Oui, j'ai eu connu l'époque des premiers PC qui nous laissait accéder à pas mal de choses. Et qui coûtaient chers.
Autrement dit, mes expérimentations n'étaient pas accueillies avec joie.
Comme j'ai programmé un driver sous linux étant jeune, j'ai quand même réussi à passer la barrière du hardware : mais elle n'est plus aussi facile.
Quand je faisais de l'assembleur motorola on avait des vecteurs d'interruption et on filait du code à executer au mode superviseur en échange de drop de privilège pour des évènements précis.
Un peu eBPF sous linux en version proche du métal. Et le superviseur, supervisait sans interaction avec le coté utilisateur sauf parfois pour balancer des bombes sur l'écran quand on déconnait.
Le PIC (programmeur d'interruption contrôlable) et sa gestion est le modèle mental que j'ai d'une pile d'évènement efficiente où je programme en bottom half laissant une unité d'exectution paraissant invisible executer mon code et me tapant sur l'épaule quand il a été appelé.
En HP48 pour passer la barrière du je peux cramer des circuits on avait le SYSEVAL qui appelait du micro-code sur lequel il n'y avait pas la mammothesque charge de CPU du typage.
La HP48 était en FORTH, et le FORTH "utilisateur" n'était en fait qu'un FORTH executé en REPL sur un FORTH machine blindé de macro en forth. L'une des beautés du FORTH c'est la capcité à l'étendre en forth sous forme de MACRO.
Le FORTH était vu comment l'engin du diable, le virus que tout le monde déteste car l'automodification du code par lui même n'est pas un tabou.
Tu peux faire muter un langage qui est unsafe vers un langage safe. Si tu es sûr de ton coup tu peux même effacer la porte de sortie vers le langage unsafe (en effaçant SYSEVAL) et brûler à jamais les ponts vers la sysntaxe machine.
En BASIC sur des processeurs ou apparaissait l'interfaçage du matériel au travers de registre mémoire dédiés, on accédait comme sous linux aux parties qui te laisse tout cramer : les périphériques. Fallait avoir le manuel de charabia du périphérique, où est quoi ? Comment ça cause ?
On a remplacé les TRAP des ROMs des M68K, Z80 depuis longtemps par des routines en BIOS, puis en UEFI mais on a toujours accès au mode superviseur...
Le plus drôle et que l'on a remplacé des adresses avec du codes machine en ROM par des machines sous unix qui émulent cette mécanique. Je trouve ça un poil délirant.
Tout ça vient d'une question lancinante à laquelle on a pas trouvé de réponse satisfaisante qui est : comment faire faire du boulot par des robots ?
L'imprimante, depuis qu'on l'a ça change bien la vie.
Même quand tu bougonnes que tu imprimes pour scanner, quand t'as connu les files d'attentes pour les CERFA à la mairie ... T'es heureux de pouvoir produire du document.
Certes depuis que l'on peut imprimer plus facilement, la bureaucratie, plus roseau que chêne, déchaînée a multiplié les formulaires.
Les imprimantes sont construites avec une machine virtuelle FORTH en tête qui contrôle des machines outils vectorielles.
Tu dis à une imprimante en postscript des choses comme dessine une ligne de là à là avec un bel arrondi.
L'imprimante virtuelle fait l'appel à sa routine pour tracer comme elle veut.
La rasterisation qui a popularisé le postscript consiste à faire dessiner dans un bitmap mémoire une imprimante virtuelle et ensuite passer ce résultat à un moteur ligne à ligne qui mélange les couleurs de ses buses pour obtenir la couleur du pixel point par point.
Le FORTH permettant par la refédinition à la volée de la macro LINE d'avoir un code multi-cible (écran ou papier) sans modification. Ca a été les promesses d'une chaîne graphique haute fidélité en PAO et même l'éphémère DisplayPostscript inclus dans Next qui ont été acquise avec Steve Jobs.
Le FORTH modélise une unité d'execution dans un machine virtuelle avec des états globaux (genre la taille des pages). Mutables ... Et une gestion des risques critiques succintes (la machine outil peut déclencher un TRAP quand elle est en panne).
La raison pour laquelle nos appels de fonctions sont en conventions C et non par la pile c'est une vieille dispute de gâteux sur les architectures à registres.
PHK rappelle qu'il n'y a aucun bénéfice mesurables à ne pas travailler sur la pile directement...
Une fonction FORTH, c'est une série DATA + CODE que tu copies sous un FRAME global et tu REPL.
Actuellemment, ton ABI ARM ou INTEL sous le capot, t'as du microcode fait en vrai micro langage machine (avec des registres et des mémoires) qui te fait du REPL sur l'assembleur que tu files.
Nous informaticiens modernes n'avons jamais été autant coupé du physique que nous prétendons contrôler.
Le code que nous manipulons est toujours un langage interprété qui choisit ce que nous avons le droit de lire et écrire.
Par exemple, la gestion des exceptions mémoires sur les hit/miss des caches est gérée par du microcode. Est ce que plutôt que bidouiller au niveau OS pour changer la taille des pages de caches ce ne serait pas mieux de pouvoir compter sur des SOCs ou peut être changer le microcode ? Ah : mais pas touche, seuls les ingénieurs Intel/AMD paraît il sont capables de toucher à ça sans tout faire péter.
Je veux dire, les CPUs modernes sont en kit, surtout les ARMs. Quelque part l'état global, tu as envie que l'OS et le matériel se fassent confiance pour respecter le même contrat d'interface et que la gestion des fautes mémoires ait une version logicielle en langage de haut niveau facile à lire (un fallback générique), qui est transpilable en forth, qui est produisible sous forme d'une macro FORTH interprétable par une machine virtuelle phyisque ou logique qui cause à un composant électronique et qui si est présent sera utilisable par l'OS sans modification de code (seulement la redéfinition de certaines du langage lui même). Le monkeypatching ultime.
Ca implique que le langage permette uniquement d'executer des fonctions synthétisables/modélisables. Plutôt que de faire des démonstrateurs formels pour prouver si une fonction informatique est décidable on pourrait dire : si tu ne peux pas la produire sous forme d'un composant électro/physique ta logique n'est pas conforme à un problème réel.
Un langage dont la finalité est non de décrire des fonctions de haut niveau, mais des composantes physiques que l'on peut interfacer à d'autres circuits logiques.
Un peu comme VHDL qui permet de redéfinir par exemple les valeurs d'entrées de vrai et de faux pour accepter un type booléen réel nécessaire à la conversion vers le booléen du codeur.
Un langage dont la boucle de REPL est suffisamment facile à écrire que l'on puisse simuler de nouveaux comportements d'entrées sorties avec notre matériel que l'on veut rendre obsolète facilement.
Voir même comme le prouve le très éxigeant monde de l'émulation de borne d'acarde en synthétisant la fonction sur un support "semi matériel" aka le FGPA.
Un FGPA par exemple, ça permet de faire des calculs spécialisés en certaines transformation de traitement du signal inaccessibles avec une CPU orientée exécution en série.
La machine de turing elle est gentille, mais elle scale pas facile.
Je vais vous donner un exemple : Se déplacer d'une case, c'est bien, mais la machine de turing voit un pas en avant puis un arrière comme équivalent à une pas en arrière puis en avant.
C'est logique Turing travaillait avec des circuits électriques, donc, il avait en tête une "logique bas niveau" ou l'addition, la multiplication sont PHYSIQUEMENT commutatives.
Mais si tes portes d'entrées sont quantiques, tu ne manipules plus une algèbre linéaire, mais hermitienne. A puis B est différent de B puis A.
Et les registres ne contiennent plus des bits, mais des densités de probabilités que l'on manipules avec des phénomènes physiques pour en modifier les poids.
La densité de probabilité une fois que tu la mesures, tu la détruis irréversiblement, donc, tu ne peux plus la maniper. Le garbage collector ultime qui nettoie toutes les variables temporaires ultérieures qui ont menées à ce résultat.
Par contre, tu factorises un nombre en un cycle d'horloge si tu positionne bien tes appareils.
La physique ça se modélise bien. Mais n'attendez pas des miracles : simuler une physique hautement parallèle en pas à pas c'est rédhibtoire.
C'est là où rentre en compte les FPGA et les analyses de point chaud dans du code statique.
Avec un FGPA router des circuits de logiques vectorielles, c'est les doigts dans le nez avec en plus l'avantage de pouvoir tirer parti de phénomène physique comme les shifts register propres aux DSP yamaha pour la synthèse FM.
C'est pas aussi rapide que le VRAI truc, mais ça peut être plusieurs ordres de grandeur plus rapide qu'une machine virtuelle pas à pas synchrones.
Une machine virtuelle que tu as modélisé avec un hardware minimale virtuel, un mode superviseur minimal (pour éviter de cramer les circuits), un mécanisme de monkeypatching à la volée du langage lui même qui rend indistinguable l'execution d'une fonction logicielle bas niveau, émulée dans un interpréteur d'une VM à la webasm ou docker, ou même du résultat d'un dialogue rendu transparent avec du hardware ou la macro générique qui fait son boulot d'implémentation de référence en travaillant dans sa pile et son contexte.
Ca va demander d'aller bas, très bas, jusqu'à redéfinir ce que l'on sait sur les valeurs physiques que l'on manipule et que l'on va normaliser.
Un FORTH qui permettrait de faire table rase du passé doit être pareil à VHDL capable de simuler son fonctionnement lui même en pouvant changer les fondements mêmes des lois auxquelles répondent les valeurs dites logiques et leur encodage.
C'est un travail de titan que je me sens incapable de commencer.
Par contre, FORTH se prête bien par son faible niveau de complexité à expérimenter. A étendre, à modéliser, à sérialiser des machines à états dont on aimerait peut être distribuer le comportement sans trop d'altérations.
Une VM épurée, amish dont le rôle est d'être aussi bienveillante pour l'électronicien, l'opérateur, le chercheur et le concepteur. De définir un lieu d'interface clair qu'il soit logiciel ou matériel permettant à toute et à tous la partie la plus importante de "hello world" : celle qui permet que cette commande change le monde physique. Coder : c'est pas écrire "salut" sur un écran et changer ce que l'on écrit, mais changer comment on l'écrit.
Pour ça il faut remettre le semi-conducteur à effet physique au bas de la full stack moderne, et le processeur en haut et arrêter de se branler la nouille sur le web et la crypto.
Nous devons pouvoir recabler nos propres matériels, avoir un truc à pas cher qui fait la même chose qu'une fonction logicielle pure qui le modélise et que l'on peut fournir à une usine pour produire à pas cher dans un langage normalisé, et que l'on doit pouvoir déposer à l'OMPI comme preuve irréfragable que l'on en est l'auteur.
Quelque chose de suffisamment descriptif pour faire sens auprès de littéraires (comme les avocats et les greffiers).
Bref, j'attends avec gourmandise le moment où les cours de FORTH deviendront obligatoire pour espérer devenir un avocat.
Parce que, je m'égare, mais nos lois aussi sont des codes modélisés qui sont interprétés. Et peut être que si on modélisait la loi dans du code, on rendrait la critique de la loi aussi passionante qu'un bête problème de troubleshooting sur lesquels plus de personnes pourraient avoir un avis éclairé.
No comments:
Post a Comment