Do certain languages have intrinsic processor architectures by-design

Question

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?

Answer 1

Yes they do. For example, the Occam programming language was originally targerted specifically at the Transputer architecture.

Answer 2

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.

Answer 3

Yes, definitely... it goes the other way as well: many hardware architectures are designed to accommodate certain languages.

• RISC architectures are very much an answer to that people moved from assembly to compiled languages like C/C++.
• Burroughs B5000 had Algol instead of assembler.
• There are several different Forth chips.
• Lisp machines were designed to run Lisp efficiently.
• Java processors run Java bytecode in hardware.
• Some ARM processors have (optional) Java acceleration technology.

Probably many more good examples are available.

Answer 4

Most languages target Von Neuman architecture, which is the basis of most CPU.

Occam for Transputer, mentionned 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.

Answer 5

The best known example is of course c

Answer 6

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.

Answer 7

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?