Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I was reading this article: A Critique of Common Lisp and finding it hard to make out the precise definition of "stock-hardware machine" and its difference with "micro-coded" machines. I tried to search for a precise definition of the former to no avail.

What I currently construe stock-hardware machine to be is that, it refers to the computer chip-set commonly available in the market (without much customization).

So given that I would like to ask, what is meant by a stock-hardware machine (in the context of the paper) and how does it differ from a micro-coded machine?

share|improve this question
add comment

3 Answers

up vote 11 down vote accepted

Stock hardware basically means "not customized," as you surmised. Which customizations it refers to depends on the context. In the context of the paper, it means a computer which is not micro-codable. Micro code is to machine code as assembly is to a high-level language. It breaks down each instruction into smaller parts. On most processors, the microcode is completely unchangeable, even by assembly programmers, because it is baked into ROM at the fab. On some supercomputers you can change it. The authors are arguing that Common LISP isn't as efficient on computers where the micro code cannot be customized.

share|improve this answer
    
Note that much early LISP work was done on PDP-10 systems, which did have a writable control store (basically a way to add custom instructions to the CPU), so it was easy to compare the performance of native vs. micro-coded implementations. The early Symbolics LISP machines were also micro-codable. –  TMN Apr 3 '13 at 19:20
add comment

In the context of the paper you linked, the words "micro-coded machine" would almost certainly refer to a Lisp Machine.

At the time Lisp was beginning to get a foothold, it was hoped that it would be run (in the general case) on machines that were designed specifically to execute Lisp instructions, rather than computers with a more general instruction set intended to be used with compilers and interpreters for any language.

Microcode is what happens underneath the actual processor instructions. The processor that you are using to read this right now has machine instructions that are almost certainly implemented in some sort of microcode. But at that time, there were probably machines that

  1. Implemented machine instructions in hardware; that is, logic gates, and
  2. Machines that implemented advanced processor instruction sets (Lisp being one example) in microcode.

The former type would have been referred to as "stock hardware." The paper's point, of course, is that any machine designed specifically to execute Lisp instructions directly would have been much better at executing Lisp programs than a machine which required translation of the Lisp instructions to some other instruction set.

At the time the paper was written, this distinction would have been very important, because there were unavoidable memory and processor constraints that no longer exist today.

share|improve this answer
1  
I'd note that these days the speed of instruction decode and access to L1 cache is such that it's almost like you write microcode (and have a gigantic collection of registers too). It's these sorts of things that have massively reduced the need for dedicated Lisp support instructions; there's just not that much penalty for writing it in general code, and there's lots to be gained from using systems produced by very good hardware design teams… –  Donal Fellows Apr 3 '13 at 19:23
3  
@DonalFellows: there are a couple of fundamental design decisions in most modern mainstream CPUs that extremely penalize object-oriented languages over ADT-oriented languages, as well as memory-safe languages over memory-unsafe languages. For example, virtual memory can have a performance hit on garbage collection of up to 40%, but doesn't actually make sense: you don't need memory protection if you cannot even access memory. Likewise, OO doesn't have spatial or temporal locality, so all the usual strategies of avoiding cache misses don't work, you need to make misses cheaper not avoid them. –  Jörg W Mittag Apr 4 '13 at 1:49
5  
See the Azul Vega-3 CPU for an example of how a CPU for memory-safe OO languages might look like. It was specifically designed as a compiler target for a JVM JIT. The CPU actually is a slightly modified off-the-shelf RISC design, the really important thing is the memory controller: a Vega system with 16 CPUs (864 cores) can have over 20000 outstanding cache misses in flight and still make progress on all 864 cores. OTOH, stuff like memory prefetching and the like is very simple. The design and transistor resources went into the memory controllers instead. –  Jörg W Mittag Apr 4 '13 at 1:51
1  
@JörgWMittag AWESOME extra information. Much appreciated! I'm going to go ask another question about the ADT stuff you mentioned above now because I would love to hear more details on that! –  Jimmy Hoffa Apr 4 '13 at 15:55
    
@JörgWMittag programmers.stackexchange.com/questions/193905 –  Jimmy Hoffa Apr 4 '13 at 16:09
add comment

In the mid 70s (almost 40 years ago) a few Lisp Machines started to appear. Xerox (PARC) and MIT were developing them. Later Symbolics, LMI, TI and some others. Xerox was using one of their typical bit-slice processors and MIT developed a custom processor (CONS and then the CADR). The Xerox processor was used in a computer which also could run their office software suite and the Smalltalk software. The Xerox processor was using different instruction sets for each. The instruction sets of the processor was programmed in microcode. The MIT Lisp machine also had a processor, which could be programmed in microcode - but it was only used for Lisp. At that time processors were not microprocessor CPUs like today, but one or several boards which make a single CPU. Most computers during the 70s capable of running Lisp were time-shared mainframes or so-called mini-computers (often machines from DEC). Workstations or powerful personal computers did not exist then. The Lisp Machines were designed to be the first personal workstations (single user, no time-sharing, large address space, bitmap display, graphics, mouse, network, ...). To run Lisp efficiently with the processor technology at that time, they needed customized instruction sets. We are talking about early machines with around 1 MB RAM, virtual memory on disk, and less than 1 MIPS (million instructions per second).

The microcoded machines had specially crafted instruction sets to support the execution of Lisp (stack architecture with stack instructions, generic arithmetic, fast function calls, Lisp datatypes, GC support, ...). In the case of the MIT Lisp Machine, the hardware itself also had extensions (like special memory word widths).

The stock-hardware computers were using CPUs like the DEC VAX, Motorola 68k, Intel 86 and later SPARC, POWER, MIPS, ALPHA and many others. These computers used the CPUs like they came from the manufacturer (DEC, Motorola, Intel, IBM, ...). Beyond simple bug fixes (and Lisp developers found several bugs in CPUs) there was no special adaption of the instruction set of these computers while they were running Lisp. Some of them even might have been able to have loadable microcode - but it was not used for Lisp.

The microcoded Lisp CPUs allowed very simple instruction sets and thus a relatively simple Lisp compiler. Additionally some variants allowed to compile simple Lisp functions to microcode. The MIT used a custom CPU, because they wanted a large address space for Lisp, compact code and quick execution for the first personal workstations. A combination which was not available on the market at that time (1970s/ early 80s). Note that these CPUs appeared before Common Lisp (which was first published in 1984). Over time the manufacturers moved the CPUs through different technologies and different Lisp versions. Thus they added support for object-oriented programming (Flavors, CLOS) and logic programming to the instruction sets. It was not unusual for a new Lisp release to also come with an improved microcode with new/improved instructions. Later TI and Symbolics developed microprocessors - single-chip CPUs for Lisp. At least the Symbolics chip was not designed to support loadable microcode.

Summary:

microcoded machines are computers with either bit-slice CPUs or special Lisp cpus with special instruction sets for Lisp.

stock-hardware machines are computers with typical commercial CPUs, as they were designed by the manufacturer - without special Lisp support. Of the later stock hardware machines only the SPARC architecture contains a very tiny amount of support for Lisp (and Smalltalk).

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.