From semion.ababo at gmail.com Wed Aug 18 12:50:42 2010 From: semion.ababo at gmail.com (Semion Prihodko) Date: Wed, 18 Aug 2010 15:50:42 +0300 Subject: [movitz-devel] Lisp compilation principles and SBCL internals Message-ID: Hi guys, I'm a developer who likes to learn more about SBCL runtime internals. Being on very early stages of new OS development I need to understand is it worthy to build OS on top of lispy runtime. I see lisp-like language as a main system language (like C language in Unix-like systems), so I need to know if replacing ordinal stack / register virtual machine (I prefer a managed environment) by a lisp runtime virtual machine will make programs run more efficient? I will describe my view. Let's imagine lisp runtime operating with machine size numbers (arbitrary size numbers are on a layer above), explicitly supporting arrays, different VOPs, etc. On the layer above there is a main lispy language compiler. The question is the following: will the lisp runtime playing the part of a virtual machine be worth to base on (supposing that main language compiler will be able to pass intermediate code to it more preserving original semantics for optimization purposes compared to ordinal stack / register virtual machine)? My substantial lack of knowledge about modern lisp compilation forces me to ask another, maybe stupid question. Is the lisp compilers at general embed a minimal interpreter to compiled code? I mean, when I define a function with some work flow (conditions, recursion, etc) is it interpreted on the low level (of course, with some VOP blocks of machine code inlined and some optimization transformations applied)? Under interpretation I understand the process that flow in lisp processors (chips), well described in the following white paper: ?Design of LISP-Based Processors or, SCHEME: A Dielectric LISP or, Finit Memories Considered Harmful or, LAMBDA: Ultimate Opcode? by Guy Lewis Steele Jr. and Gerald Jay Sussman. Thanks in advance. -------------- next part -------------- An HTML attachment was scrubbed... URL: