GHDL est un logiciel écrit en Ada permettant de faire l'analyse, la compilation, la simulation ainsi que la synthèse du VHDL. Le VHDL, quant à lui, est un langage de description matériel très utilisé dans le développement sur FPGA ou ASIC. À l'origine, GHDL est un « side-project » de Tristan Gingold lui permettant de se faire la main avec Ada.
GHDL est devenu l'outil indispensable pour faire de la simulation VHDL aujourd'hui. Après presque 20 ans de développement, voici que sort en version 1.0.0 le logiciel de simulation VHDL nommé GHDL. En prime, GHDL s'offre un nouveau logo:
Peu d'informations ont filtré sur cette sortie pour le moment. On peut soupçonner que ce soit une sortie anniversaire pour marquer les 20 ans du logiciel. Il n'en reste pas moins que GHDL est devenu un maillon indispensable dans l'écosystème opensource du monde FPGA et des ASIC.
Cette version 1.0.0 supporte désormais complètement les standards 1987, 1993 et 2002 du langage défini par l'IEEE. Le support de VHDL 2008 est noté comme partiel pour le moment.
Depuis quelques années, le développement du projet s'est accéléré et supporte de mieux en mieux les projets tierces comme Yosys bien sûr mais également CocoTB pour les testbenchs écrit en Python ainsi que les standards de vérification comme UVVM, OSVVM, VUnit issues du standard d'accelera.
Un support partiel d'un langage de PSL (Properties Specification Language) est également inclus. Il permet de décrire les propriétés du système pour faire de la vérification formelle.
Et surtout, il est possible de faire de la Synthèse. Certes, l'extension ghdl-yosys-plugin est encore en développement, mais l'exemple TapTempo l'a montré : Il est tout à fait possible de faire de la synthèse VHDL avec.
Cette version mature est surtout une occasion de mettre en valeur cet outil indispensable dans le monde du développement numérique (gateware).
# En...age de mouche
Posté par Blackknight (site web personnel, Mastodon) . Évalué à 9.
En fait, c'est Ada, pas ADA.
Le langage tire son nom d'Ada Lovelace qui n'aurait certainement pas aimé que son prénom soit écrit sous la forme d'un sigle :)
Sinon ADA, c'est au choix :
- Un loueur de voiture
- L'American Dental Association
- Entre autres
Voilà, c'est tout :)
[^] # Re: En...age de mouche
Posté par Ysabeau 🧶 (site web personnel, Mastodon) . Évalué à 5. Dernière modification le 06 février 2021 à 17:58.
Non, non, je te rassure, tu ne t'es pas livré à des choses pas convenables sur des mouches. Tu as eu tout à fait raison de relever la graphie que j'ai donc corrigé en espérant ne pas avoir oublié d'occurrence.
« Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.
[^] # Re: En...age de mouche
Posté par Blackknight (site web personnel, Mastodon) . Évalué à 3.
Merci
PS : C'est une maladie chez les Adaistes de reprendre tout le monde là-dessus :D
[^] # Re: En...age de mouche
Posté par abriotde (site web personnel, Mastodon) . Évalué à 1.
J en conclu que tu est adaïste. Si je puis me permettre cette question, aujourd'hui quel est l'intérêt/apport/utilité d'Ada?
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
[^] # Re: En...age de mouche
Posté par Blackknight (site web personnel, Mastodon) . Évalué à 7.
Il suffit de regarder mes derniers journaux/dépêches mais je suis aussi BSDisteet je code en d'autres langages aussi , c'est pas limité en fait :)
Vaste question ! Je vais y répondre très rapidement
[^] # Re: En...age de mouche
Posté par martoni (site web personnel, Mastodon) . Évalué à 2.
En tant que Adaïste, que pense tu du petit nouveau Rust ? Est-il un bon remplaçant pour Ada ?
J'ai plus qu'une balle
[^] # Re: En...age de mouche
Posté par Blackknight (site web personnel, Mastodon) . Évalué à 3. Dernière modification le 07 février 2021 à 21:55.
Je n'ai pas plus regardé que ça mais de ce que j'avais vu, certaines constructions relevaient de la contorsion plus qu'autre chose… Mais bon, mon jugement date un peu (cf. ce billet et mes commentaires).
Après, on dit qu'Ada est verbeux mais le Rust se défend pas mal dès qu'il s'agit de faire des templates :D
Pour savoir si c'est un bon remplaçant, il faudra attendre un peu… Et puis, il manque quand même encore des trucs comme le typage très fort ou la représentation en mémoire ;)
Et puis Rust a encore des macros !!! :D
Par contre, la possession de pointeurs est clairement une bonne idée… Tellement bonne, qu'on la trouve dans Spark :)
Bon, promis, je vais essayer de faire le tuto Rust… Ou alors un tuto Ada pour STM32 sur Hackable :D
[^] # Re: En...age de mouche
Posté par Blackknight (site web personnel, Mastodon) . Évalué à 2.
Bon, je me réponds pour dire que toutefois, on peut écrire nombre de programme sans ne jamais utiliser de pointeurs :)
[^] # Re: En...age de mouche
Posté par GuieA_7 (site web personnel) . Évalué à 3.
En fait en Rust on manipule des références la plupart du temps, pas des pointeurs. Si on veut faire des choses acrobatiques comme de l'algèbre de pointeurs, ça sera dans un bloc
unsafepour des raisons assez évidentes (et c'est donc tout à fait évitable en général).Quand aux macros dont tu parles plus haut (flemme de faire un autre commentaire), il s'agit de macros façons LISP (hygiéniques, gérées par le langage) et pas façon C/C++ (gérées par le préprocesseur, simple remplacement de chaînes sans vérification de syntaxe). Ça permet notamment d'éviter le code boiler-plate de façon plutôt élégante ; mais je veux bien lire tes griefs.
[^] # Re: En...age de mouche
Posté par abriotde (site web personnel, Mastodon) . Évalué à 2.
Je me suis renseigné un peu sur Ada et Ada n'a clairement pas la même visée que Rust. Ada est plus verbeux et donc il est plus long d écrire un programme mais c'est pour qu'il puisse être vérifié au sens que l'on peut vérifier qu il respecte un cahier des charges. Il est par contre moins performant que Rust.
Rust est destiné à faire un programme informatique sécurisé et performant (OS ou application) Ada se tourne plus vers une application critique bancaire, administrative ou d'avion. En Rust on fais attention à la sécurité informatique en Ada a ce que le résultat donne (int négatif après une addition de positif à cause d un débordement).
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
[^] # Re: En...age de mouche
Posté par Blackknight (site web personnel, Mastodon) . Évalué à 4.
Alors, la verbosité est largement contrée par l'utilisation d'un IDE avec auto-completion, GPS étant un bon exemple donc dire qu'il est plus long d'écrire un programme, ça dépend aussi du programmeur.
D'ailleurs, tout le monde ne semble pas d'accord avec cette assertion (cf. là ainsi que les liens contenus).
Globalement, il est estimé que le code Ada est 30% moins performant que le C et de performance équivalente au C++ donc c'est tout à fait possible que le Rust soit plus performant dans certains cas.
Ceci dit, à l'époque des langages interprétés et d'après les discours que je lis ici-même, il semble que la performance brute ne soit plus une caractéristique primordiale.
Par contre, je suis intéressé par les sources que tu as pu trouver là-dessus.
Qu'entends-tu dans ce cas par sécurité informatique ?
Le fait que le programme ne plante pas ?
Un programme qui ne plante pas même s'il donne de mauvais résultats ?
Pour la partie OS/Application que tu mentionnes, on retrouve Ada dans des machines n'ayant même pas d'OS sous la forme d'un exécutif temps-réel embarqué.
Il y a aussi eu une tentative d'OS pour x86 en Ada mais écrire un OS complet prend du temps et le projet a fini par s'arrêter.
Pour ce qui est des applications, GHDL ne rentre justement pas dans les catégories que tu mentionnes. Par contre, il y a effectivement historiquement des niches où on retrouve Ada mais heureusement il n'y a pas que là :)
En conclusion, moi je pense que les deux langages ont bien la même visée, faire des programmes qui fonctionnent sans avoir les écueils que l'on connait en C/C++.
[^] # Re: En...age de mouche
Posté par abriotde (site web personnel, Mastodon) . Évalué à 2.
J explicite mon côté sécurité informatique: c est garantir que l on aura pas de Segfault, que la mémoire est libéré au bon moment. Ce que fait Rust en ayant des performances comparable à C (parfois Supérieur) ce qui est meilleur que C++ surtout si on utilise ses fonctionnalités avancées. La performances compte peu pour un programme qui tourne peu ou pas souvent, mais elle prends vite de l importance sur les programmes sollicités. C'est la raison pour laquelle C persiste au top des classements malgré tous ses défauts et la présence de C++, java, Go et autres python et Javascript…
Par contre Rust ne vérifie jamais que si tu additionne 2 nombre positif tu ne va pas dépasser la limite de l entier et te retrouver avec un négatif (ou un nombre plus petit). Il n y a pas de preuve possible en Rust alors qu Ada peut être prouvé je crois. La preuve est complexe à mettre en place (cher) mais utile pour des fusées…
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
[^] # Re: En...age de mouche
Posté par Joël Thieffry (site web personnel) . Évalué à 5.
Effectivement si tu utilises directement l'opération, par exemple "
2 + 2", aucun test de dépassement ne sera effectué. Par contre, je t'invite à regarder toutes les méthodes "checked_*" sur les types primitifs, qui permettent de vérifier ce dépassement, par exemple https://doc.rust-lang.org/std/primitive.u32.html#method.checked_add :(u32::MAX - 2).checked_add(1) == Some(u32::MAX - 1)
(u32::MAX - 2).checked_add(3) == None
[^] # Re: En...age de mouche
Posté par Blackknight (site web personnel, Mastodon) . Évalué à 1.
Notion qui ne s'écrit même pas en Ada :)
C'est le compilateur qui décide en fonction de la taille de la variable. Ceci dit, cela ne s'applique pas aux objets qui eux, sont toujours passés par référence.
Ce que je reproche aux macros en général, c'est que ça reste pour moi une verrue et que bien que cela soit géré par le langage et pas par un macro-processeur, on se retrouve à injecter du code là où on pourrait écrire une fonction.
Si le but est de forcer l'inlining, en Ada, il y a un aspect pour ça et on se passe très bien des macros pour le coup.
[^] # Re: En...age de mouche
Posté par GuieA_7 (site web personnel) . Évalué à 2.
Du coup c'est un gros "sauf". Et dans la mesure où Rust est utilisable pour écrire des bibliothèques comme si elle était écrite en C, on comprend la présence du concept de pointeur (je comprends qu'on veuille les proscrire dans certains cas spécifiques, mais je préfère dans le cas général l'approche où on garde sous surveillance les quelques blocs
unsafequi traînent).Je te rassure Rust sait très bien inliner. Les macros peuvent faire des choses qui ne sont pas possible avec des fonctions (en Rust) :
Plus de détails ici: https://doc.rust-lang.org/book/ch19-06-macros.html
[^] # Re: En...age de mouche
Posté par Blackknight (site web personnel, Mastodon) . Évalué à 4.
Je crois qu'on ne s'est pas compris. Les pointeurs existent en Ada, c'est ce que l'on appelle des Access et leur utilisation est très encadrée.
Par contre, la référence, telle qu'elle est écrite en C++ et en Rust avec un &, n'existe pas.
Et ce que je disais, c'est que tant que tu ne précises pas explicitement que tu passes un paramètre de type Access sur quelque chose, c'est le compilateur qui décide s'il y aura copie ou non… Sauf dans le cas des types tagués (en gros, des objets au sens instance de classe) où pour des raisons évidentes d'héritage potentiel, c'est obligatoirement une référence qui est passée (mais sans que l'on ne le précise)
Comme je l'ai dit, le concept de pointeur existe bel et bien en Ada et pour ce qui est de l'interfaçage avec le C, cela fait même l'objet d'une section spéciale dans le standard
Effectivement, ça a l'air hyper puissant
[^] # Re: En...age de mouche
Posté par Pierre Jarillon (site web personnel) . Évalué à 9. Dernière modification le 07 février 2021 à 23:12.
J'ai utilisé en 1975 le HP9825, une petite merveille à 50kF. Il utilisait le langage interprété HPL qui était extrêmement compact et performant, une aide précieuse pour les ingénieurs et les techniciens de laboratoire. Je l'ai aimé à cause de cela.
À l'opposé, j'ai pas mal écrit en Pascal que j'ai aimé pour sa rigueur malgré sa verbosité. Un programme qui compilait ne faisait pratiquement jamais d'erreur d'exécution (je n'ai pas retrouvé cela en C).
J'aurais voulu remplacer le Pascal par Ada mais le langage était vendu trop cher pour que je puisse aller plus loin et je le regrette.
Je n'ai apprécié le Fortran qu'à partir du moment où j'ai pu spécifier "implicit none" au grand dam de mes techniciens… qui ont alors vu que les erreurs lors de l'exécution devenaient rares. Vous l'avez compris, je préfère un typage fort à un core dump.
Pour moi, Ada était la suite logique du Pascal, un langage fortement typé. Sa politique commerciale l'a tué. S'il avait été libre, il aurait eu un tout autre destin.
[^] # Re: En...age de mouche
Posté par Blackknight (site web personnel, Mastodon) . Évalué à 4.
Et oui, la 1ère version de GNAT date, hélas, de 1995.
Ce qu'il faut mentionner aussi, c'est que vu la complexité de la spécification, les compilateurs étaient souvent buggés et cela n'a pas aider à la réputation du langage.
Par contre, dans la légende Ada, il est souvent dit aussi que le langage provenant d'une spécification du département de défense américain, nombre d'universitaires refusèrent de travailler avec. Je suis "trop jeune" pour abonder dans ce sens :)
Ceci dit, c'est dommage d'en parler au passé, la prochaine version du standard étant en gestation et le compilateur GNAT, dans sa version payante du moins, supportant déjà certaines des évolutions (cf. le blog d'Adacore).
Le langage est donc toujours vivant… Preuve en est, on a sous les yeux une nouvelle version de GHDL :)
[^] # Re: En...age de mouche
Posté par Joël Thieffry (site web personnel) . Évalué à 2.
J'espère que ces personnes n'utilisent pas l'Internet (dont les briques de base, oui gros raccourci, ont été spécifiées dans le projet ARPAnet par le même DoD) :)
[^] # Re: En...age de mouche
Posté par Ysabeau 🧶 (site web personnel, Mastodon) . Évalué à 6. Dernière modification le 07 février 2021 à 23:43.
Pierre, tu pourrais (devrais) faire une dépêche sur ce sujet. Ça serait passionnant.
« Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.