How have languages influenced CPU design?

Question

We are often told that the hardware doesn't care what language a program is written in as it only sees the compiled binary code, however this is not the whole truth. For example, consider the humble Z80; its extensions to the 8080 instruction set include instructions like CPIR which is useful for scanning C-style (NULL-terminated) strings, e.g. to perform strlen(). The designers must have identified that running C programs (as opposed to Pascal, where the length of a string is in the header) was something that their design was likely to be used for. Another classic example is the Lisp Machine.

What other examples are there? E.g. instructions, number and type of registers, addressing modes, that make a particular processor favour the conventions of a particular language? I am particularly interested in revisions of the same family.

Answer 1

The existing answers focus on ISA changes. There are other hardware changes, too. For instance, C++ commonly uses vtables for virtual calls. Starting with the Pentium M, Intel has an "indirect branch predictor" component which accelerates virtual function calls.

Answer 2

The Intel 8086 instruction set includes a variation of "ret" which adds a value to the stack pointer after popping the return address. This is useful for many Pascal implementations where the caller of a function will push arguments onto the stack before making a function call, and pop them off afterward. If a routine would accept e.g. four bytes' worth of parameters, it could end with "RET 0004" to clean up the stack. Absent such an instruction, such a calling convention would likely have required that code pop the return address to a register, update the stack pointer, and then jump to that register.

Interestingly, most code (including OS routines) on the original Macintosh used the Pascal calling convention despite the lack of a facilitating instruction in the 68000. Using this calling convention saved 2-4 bytes of code at a typical call site, but required an extra 4-6 bytes of code at the return site of every function that took parameters.

Answer 3

One example is MIPS, which has both add and addu for trapping and ignoring overflow respectively. (Also sub and subu.) It needed the first type of instruction for languages like Ada (I think--I've never actually used Ada though) which deal with overflows explicitly and the second type for languages like C that ignore overflows.

If I remember correctly, the actual CPU has some additional circuitry in the ALU for keeping track of overflows. If the only language people cared about was C, it wouldn't need this.

Answer 4

The Burroughs 5000 series was designed to efficiently support ALGOL, and Intel's iAPX-432 was designed to efficiently execute Ada. The Inmos Transputer had it's own language, Occam. I think the Parallax "Propeller" processor was designed to be programmed using its own variant of BASIC.

It's not a language, but the VAX-11 instruction set has a single instruction to load a process context, which was designed after a request from the VMS design team. I don't remember the details, but ISTR it took so many instructions to implement that it put a serious upper limit on the number of processes they could schedule.

Answer 5

IBM's Z series mainframe, is the descendant of the IBM 360 from the 1960s.

There were several instructions which were put there to specifically to speed up COBOL and Fortran programs. The classic example being the BXLE – "Branch on Index Low Or Equal" which is most of a Fortran for loop or a COBOL PERFORM VARYING x from 1 by 1 until x > n encapsulated in a single instruction.

There is also a whole family of packed decimal instructions to support fixed point decimal arithmetic common in COBOL programs.

Answer 6

The Motorola 68000 family introduced some autoincrement adressmode that made copying data through the cpu very efficient and compact.

[Updated example]

this was some c++ code that influenced 68000 assembler

while(someCondition)
    destination[destinationOffset++] = source[sourceOffset++]

implemented in conventional assembler (pseudocode, I forgot the 68000 assembler commands)

adressRegister1 = source
adressRegister2 = destination
while(someCondition) {
    move akku,(adressRegister1)
    move (adressRegister2), akku
    increment(adressRegister1, 1)
    increment(adressRegister2, 1)
}

with the new adressmode it became something simmilar to

adressRegister1 = source
adressRegister2 = destination
while(someCondition) {
    move akku,(adressRegister1++)
    move (adressRegister2++), akku
}

only two instructions per loop instead of 4.

Answer 7

Early Intel CPUs had the following features, many of them now obsoleted in 64-bit mode:

• ENTER, LEAVE and RET nn instructions [early manuals told explicitly those were introduced for block structured languages, e.g., Pascal, which supports nested procedures]
• instructions for speeding up BCD arithmetic (AAA, AAM, etc.); also BCD support in x87
• JCXZ and LOOP instructions for implementing counted loops
• INTO, for generating a trap on arithmetic overflow (e.g., in Ada)
• XLAT for table lookups
• BOUND for checking array bounds

Sign flag, found in the status register of many CPUs, exists to easily perform signed AND unsigned arithmetic.

SSE 4.1 instruction set introduces instructions for string processing, both counted and zero-terminated (PCMPESTR, etc.)

Also, I could imagine that a number of system-level features were designed to support safety of compiled code (segment limit checking, call gates with parameter copying, etc.)

Answer 8

One thing nobody seems to have mentioned so far is that advances in compiler optimization (where the base language is largely irrelevant) drove the shift from CISC instruction sets (which were largely designed to be coded by humans) to RISC instruction sets (which were largely designed to be coded by compilers.)

Answer 9

Some ARM processors, mainly those in mobile devices, include(d) Jazelle extension, which is hardware JVM interpreter; it interprets Java bytecode directly. Jazelle-aware JVM can use the hardware to speed up the execution and eliminate much of JIT, but fallback to software VM is still ensured if bytecode cannot be interpreted on chip.

Processors with such unit include BXJ instruction, which puts processor in special "Jazelle mode", or if activating the unit had failed, it is just interpreted as normal branch instruction. The unit reuses ARM registers to hold JVM state.

The successor to Jazelle technology is ThumbEE

Answer 10

As far as I know this was more common in the past.

There is a session of questions in which James Gosling said that there were people trying to make hardware that could deal better with JVM bytecode, but then these people would find out a way to do it with common "generic" intel x86 (maybe compiling the bytecode in some clever way).

He mentioned that there is advantage in using the generic popular chip (such as intel's) because it has a large corporation throwing huge sums of money at the product.

The video is worth checking out. He talks about this at minute 19 or 20.

Answer 11

I did a quick page search and it seems that no one has mentioned CPU's developed specifically to execute Forth. The Forth programming language is stack based, compact, and used in control systems.

Answer 12

The 68000 had MOVEM which was most suited to pushing multiple registers onto the stack in a single instruction which is what many languages expected.

If you saw MOVEM (MOVE Multiple) preceding JSR (Jump SubRoutine) throughout the code then you generally knew that you were dealing with C complied code.

MOVEM allowed for auto increment of the destination register allowing each use to continue stacking on the destination, or removing from the stack in the case of auto decrement.

http://68k.hax.com/MOVEM

Answer 13

The Intel iAPX CPU was specifically designed for OO languages. Didn't quite work out, though.