Je suis curieux de savoir si certaines langues sont, par leur conception, mieux adaptés à certaines architectures de processeur. Quand je parle d'architectures, je ne parle pas d'ARM/PPC/MIPS mais d'architectures basées sur des piles, des accumulateurs ou des registres.faire certaines langues ont des architectures de processeurs intrinsèques par la conception
Par exemple, je peux penser à Forth, qui est une architecture de pile. D'autres?
Oui, définitivement ... ça va aussi dans l'autre sens: de nombreuses architectures matérielles sont conçues pour s'adapter à certaines langues.
Probablement beaucoup d'autres bons exemples sont disponibles.
Oui, ils le font. Par exemple, le langage de programmation Occam a été initialement conçu spécifiquement pour l'architecture Transputer.
Peut-être est un peu d'une réponse intelligente cul, mais:
Les langages d'assemblage des processeurs concernés sont étroitement liés à l'architecture, donc, oui, il existent des langues où il est vrai.
Que présentent les mêmes langues de niveau supérieur est peut-être plus intéressant.
La plupart des langues ciblent Von Neumann architecture, ce qui constitue la base de la plupart des CPU.
Occam pour Transputer, mentionné par Neil Butterworth est une exception notable.
VHDL est une autre exception, basée sur le concept de flux de données, mais ce n'est pas un langage de programmation, c'est une description matérielle et un langage de simulation.
Le meilleur exemple connu est bien sûr c
Pourriez-vous élaborer là-dessus? Pour quelqu'un qui a cette question, votre réponse n'est pas évidente et donc probablement pas utile. Pourquoi "bien sûr"? –
C a été écrit au début des années 1970, en fonction de DEC PDP-11 par exemple Sur le PDP-7, le langage de programmation B ne disposait que d'un type de données, mais en le transférant au PDP-11 qui avait des types de données de tailles différentes, les types de données pour les variables étaient ajoutés à la langue.
j'ai vu une discussion sur Google Video par Simon Peyton Jones qui a parlé à ce sujet. Il a mentionné qu'à l'époque les gens étaient très intéressés par l'écriture de matériel spécialisé pour exécuter une langue particulière, mais les gens ont trouvé une meilleure façon de résoudre le problème: rendre le compilateur plus intelligent. Jetez un oeil à Haskell. GHC produit un code ridiculement rapide à partir de constructions de haut niveau, mais Haskell est tellement différent de l'assembleur x86 que les deux semblent étrangers l'un à l'autre.Le même genre de chose s'est passé avec Java et Lisp: Java et Lisp sont très rapides sur les ordinateurs modernes et prennent un avantage décent de nos processeurs, mais Java a été initialement compilé pour un bytecode bizarre basé sur une pile et il y a longtemps, les gens construisaient des machines Lisp.
Voici la vidéo, soit dit en passant. La plupart d'entre elles ne sont pas pertinentes pour la question actuelle, mais vous pouvez trouver cela intéressant, c'est pourquoi «la programmation fonctionnelle est importante» et comment simplifier les tests unitaires.
http://video.google.com/videoplay?docid=-4991530385753299192&hl=en
Il a seulement été assez récent (dernière décennie?) Que les compilateurs ont été assez intelligents pour faire Haskell et Java presque aussi vite que C, même si aucun d'entre eux exposent une grande partie de l'architecture sous-jacente. Heck, GHC n'utilise même pas la pile, comment est-ce wacky?
+ Battez-moi sur Burroughs et Lisp. Notez que l'architecture "call by name" d'Algol nécessitait une "liste d'affichage" (prédécesseur des "continuations" et des "expressions-lambda" d'aujourd'hui) et le supportait dans le matériel. –
... Il y a eu un moment dans les années 70 et 80 où il a semblé que la prochaine vague devait générer, pas un langage machine spécifique à l'application (ce que font les compilateurs), mais des circuits intégrés spécifiques à l'application (ASIC). Alors, pendant un certain temps, le matériel essayait de devenir le nouveau logiciel. –