From: sdm7g@aemsun.med.Virginia.EDU (Steven D. Majewski)
Newsgroups: comp.arch,comp.lang.misc
Subject: Interpreted code penalties (was: Re: Ideas for new LISP Machines)
Keywords: LISP-machines, interpreters
Date: 10 Apr 92 15:50:12 GMT
Followup-To: comp.arch
Organization: University of Virginia



 In article <1992Apr1.033547.20514@athena.mit.edu>, pdp8@m4-035-4.MIT.EDU (John W.F. McClain) writes:
 > What is the general felling on purpose built LISP machines.  Ignoring
 > marketing issues do they make sense from a technical viewpoint, or is
 > it more effective to take a RS6000 or a DECstation and write a virtual
 > LISP machine.


 baechler@liasun3.epfl.ch (Emmanuel Baechler) replies:
 >
 >Purpose built LISP machines have the advantage that many of their important
 >operations are directly supported by the hardware or the microcode...
 >
 >This discussion arose several times on the Symbolics Lisp Users Groups. At
 >each time the "gurus" answered that a software simulation, although feasible,
 >would result in a very slow machine. I don't know wether this situation has
 >really changed with the new RISC machines. There was also a time where TI was
 >developing a microprocessor with writable microcode. This can be a solution,
 >if it ever succeeds.
 >

 The RISC philosophy has often been characterized as "User level micro-code" - 
 rather than building complex instructions from simple micro-code instructions,
 make the basic user-level instructions as fast as micro-code. 
 RISC *is* microcode that uses a cache of main memory instead of a limited
 size writable control store.

 In:
   Eddy H. Debaere, Jan M. Van Campenhout. 
   Interpretation and instruction path coprocessing 
   Cambridge, Mass. : MIT Press, c1990.
 the authors describe different styles of interpreters, and various methods
 of optimization - including micro-coding the interpreter loops. They state
 that modern RISC architectures SHOULD give comparable performance to 
 microcoded interpreters - the interpreter loops are usually small enough
 to fit into cache. But that expected performance has not usually been 
 achieved because of the rather different memory reference patterns of 
 interpreted code ( often stack based, short instruction paths with lots
 of jumps, lots of indirect references, etc. )



 in Message-ID: <SIMON.92Apr2111448@liasg2.epfl.ch>
  simon@lia.di.epfl.ch (Simon Leinen) writes ( in reply to Paul Wilson ):
 >
 >Good point.  The problem with conventional architectures is not so
 >much that they are missing support in form of expensive features like
 >hardware tags etc.  It's rather that the assumptions behind the
 >existing cache and VM implementations break down in the case of Lisp
 >and friends because the access patterns to memory are very different.
 >

 I agree. See above.

 >
 >Unfortunately I never see Gabriel benchmark times in announcements for
 >new machines... which leads me to think that Lisp performance is not a
 >high-priority issue for HW vendors.
 >
 >Rather than invest in their own hardware development, Lisp
 >implementors should lobby for reasonable support from the mainstream
 >hardware vendors.  SPARC's tagged add/sub instructions are an
 >excellent example here (hopefully not the last one).
 >

 There was some discussion of the REKURSIV, iAPX-432, and other specialized
 architecture in self-interest mail-list, and some other forums: 
 The final problem always comes down to economics. Even a *GREAT* design for
 a specialized language/domain is not going to be able to keep the level of
 R&D investment to keep up with the performance increases in the competitive
 general purpose micro-processor market. ( That does *NOT* mean that RESEARCH
 groups should not try out some radical ideas - RISC may not be the FINAL 
 word in computer architecture - only the final word for the next 5 or 10
 years! :-) 

 So I agree: a new Lisp Machine is unlikely to be commercially successful.
 Better support from mainstream hardware vendors is not unreasonable: They
 need SOMETHING other than just "build bigger caches" to do with all those
 transistors :-) 

 But I would modify (generalize) the request for better support for 
 INTERPRETED and/or COMPILED-but-with-dynamic-environments languages: 
 interactive environments will be more ..., well, *interactive* ( i.e.,
 interpreted, dynamic, etc. ). PostScript is probably the most widespread
 and commercial interpreter, but along with Lisp & Scheme, we have Perl,
 TCL, Python, REXX, Forth, Basic, awk, csh, ... et.al.

 I'm sure that there are software solutions to some of the problems. 
 That's why I focus more on the memory reference patterns than tagging or
 garbage collection - I may well be wrong on this guess, but I thing that
 that is less likely to yield to a software only solution. 
 [ Actually, the FIRST question is: *Is* there a penalty for interpreted code
 running on RISC's due to different patterns of memory reference compared
 to compiled code ? I have not seen a definitive answer to this, but I have
 seen numbers that *suggest* YES. ]

 The other problem is: along with RISC instructions becoming the new
 functional equivalent of micro-code, we increasingly have C becoming
 the new functional equivalent of assembler-language. It is also partly
 a question of economics: a lot of R&D has gone ( is going ) into optimizing
 C-compilers. Most of those "higher-level" languages are going to be 
 implemented in C. (1) An architectural feature that can't be expressed well
 from C may be of limited use. (2) I'm not sure how easily and portably 
 the Self techniques can be applied in these other cases. *IF* the software
 solution is difficult and needs to be replicated slightly differently for 
 each processor/language pair, then a hardware solution makes economic sense.

 - waiting for enlightenment from the net on that last point/question. 

 - Steve Majewski


======== "If you have a hammer, find a nail" - George Bush,'91  =========
 Steven D. Majewski		University of Virginia Physiology Dept.
 sdm7g@Virginia.EDU		Box 449 Health Sciences Center
 Voice: (804)-982-0831/32	1600 Jefferson Park Avenue
 FAX:   (804)-982-1616		Charlottesville, VA 22908
Newsgroups: comp.arch