某些语言是否在设计上具有内在的处理器架构
我很想知道某些语言是否在设计上更适合某些处理器架构。 当我说架构时，我指的不是 ARM/PPC/MIPS，而是更多基于堆栈、累加器或寄存器的架构。
比如我可以想到Forth，它是一个堆栈架构。 还有其他人吗？
I'm curious to know if certain languages are, by design, better suited for certain processor architectures. When I say architectures, I don't mean ARM/PPC/MIPS but more stack, accumulator, or register based architectures.
For example, I can think of Forth, which is a stack architecture. Any others?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
是的，当然……反之亦然：许多硬件架构都是为了适应某些语言而设计的。
可能还有更多好的例子。
Yes, definitely... it goes the other way as well: many hardware architectures are designed to accommodate certain languages.
Probably many more good examples are available.
是的，他们确实这样做。 例如，Occam 编程语言最初专门针对翻译机架构。
Yes they do. For example, the Occam programming language was originally targerted specifically at the Transputer architecture.
也许这有点自作聪明，但是：
所涉及的处理器的汇编语言与体系结构紧密相关，因此，是的，确实存在一些确实如此的语言。
高级语言是否也表现出同样的情况也许更有趣。
Perhaps this is a bit of a smart-ass answer, but:
The assembly languages of the processors involved are tightly linked to the architecture, so, yes, there do exist some languages where it is true.
Whether higher-level languages exhibit the same is perhaps more interesting.
我在 Google 视频上看到西蒙·佩顿·琼斯 (Simon Peyton Jones) 的演讲谈到了这一点。 他提到，当时人们对编写专门执行特定语言的硬件非常感兴趣，但人们找到了更好的方法来解决问题：让编译器更智能。 看看哈斯克尔。 GHC 从高级构造中生成一些速度快得离谱的代码，但 Haskell 与 x86 汇编器非常不同，以至于两者看起来互不相同。 Java 和 Lisp 也发生了同样的事情：Java 和 Lisp 在现代计算机上都非常快，并且充分利用了我们的处理器，但 Java 最初是为奇怪的基于堆栈的字节码编译的，很久以前，人们构建了 Lisp 机器。
顺便说一句，这是视频。 其中大部分与当前问题无关，但您可能会发现它很有趣，它是关于“为什么函数式编程很重要”以及如何以简单的方式进行单元测试。
http://video.google.com/videoplay?docid=-4991530385753299192& 。
直到最近（最近十年左右？），编译器才足够聪明，使 Haskell 和 Java 几乎与 C 一样快，尽管它们都没有公开太多底层架构 哎呀，GHC 甚至不使用堆栈，这有多奇怪？
I saw a talk on Google Video by Simon Peyton Jones that talked about this. He mentioned that back in the day people were very interested in writing hardware that was specialized to execute a particular language, but people figured out a better way to solve the problem: make the compiler smarter. Take a look at Haskell. GHC produces some ridiculously fast code from high level constructs, yet Haskell is so much unlike x86 assembler that the two look alien from each other. The same kind of thing happened with Java and Lisp: Java and Lisp are both very fast on modern computers and take decent advantage of our processors, but Java was originally compiled for a weird stack-based bytecode and long ago, people built Lisp machines.
Here's the video, by the way. Most of it is not relevant to the current question but you may find it interesting, it's about "why functional programming is important" and how to make unit tests the easy way.
http://video.google.com/videoplay?docid=-4991530385753299192&hl=en
It's only been fairly recent (last decade or so?) that compilers have been smart enough to make Haskell and Java almost as fast as C, even though neither of them expose much of the underlying architecture. Heck, GHC doesn't even use the stack, how wacky is that?
最著名的例子当然是c
The best known example is of course c
C 是在 20 世纪 70 年代初编写的，以适应 DEC PDP-11
例如，在 PDP-7 上，编程语言 B 只有一种数据类型，但是将其移植到具有不同大小的数据类型的 PDP-11，变量的数据类型被添加到该语言中。
C was written in the early 1970s to suit the DEC PDP-11
e.g. On the PDP-7 the programming language B only had one data type, but porting it to the PDP-11 which had different sized data types, data types for variables were added to the language.
大多数语言都以 冯诺依曼架构为目标，这是大多数 CPU 的基础。
尼尔·巴特沃斯 (Neil Butterworth) 提到的 Transputer 奥卡姆 (Occam for Transputer) 是一个值得注意的例外。
VHDL是另一个例外，基于数据流概念，但它不是一种编程语言，它是一种硬件描述和仿真语言。
Most languages target Von Neumann architecture, which is the basis of most CPU.
Occam for Transputer, mentioned by Neil Butterworth is a notable exception.
VHDL is another exception, based on data flow concept, but it is not a programming language, it is a hardware description and simulation language.