<br><font size=2 face="sans-serif">Sounds like a good idea! This reminds
me on Forth and its cross compilers and recently factor.</font>
<br>
<br>
<br>
<table width=100%>
<tr valign=top>
<td width=40%><font size=1 face="sans-serif"><b>"Igor Stasenko"
<siguctua@gmail.com></b> </font>
<br><font size=1 face="sans-serif">Gesendet von: squeak-dev-bounces@lists.squeakfoundation.org</font>
<p><font size=1 face="sans-serif">01.07.2008 08:07</font>
<table border>
<tr valign=top>
<td bgcolor=white>
<div align=center><font size=1 face="sans-serif">Bitte antworten an<br>
The general-purpose Squeak developers list <squeak-dev@lists.squeakfoundation.org></font></div></table>
<br>
<td width=59%>
<table width=100%>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">An</font></div>
<td><font size=1 face="sans-serif">"The general-purpose Squeak developers
list" <squeak-dev@lists.squeakfoundation.org></font>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">Kopie</font></div>
<td>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">Thema</font></div>
<td><font size=1 face="sans-serif">[squeak-dev] [ANN] CorruptVM preview</font></table>
<br>
<table>
<tr valign=top>
<td>
<td></table>
<br></table>
<br>
<br>
<br><tt><font size=2>Since lately there a some interest in C/C++ compiling
and some people<br>
mentioned how it would be cool to make everything to be dynamically<br>
compiled,<br>
i decided to make a preview announce of a research which i done during<br>
last few months.<br>
<br>
A project name is a weird, and definitely it require more appropriate<br>
name to not scare off a potential users/developers, but this is not an<br>
issue right now :)<br>
<br>
Let me describe a little the key features of project and what goals it
pursuing:<br>
<br>
- the main goal is to create a smalltalk language environment (similar<br>
to other smalltalks), but i avoid to call it VM, because its not<br>
really a VM, because there is no VM at all.<br>
- everything is written in smalltalk<br>
- system is completely self sustaining: smalltalk code compiled down<br>
to native code (no initial need in having bytecodes). Of course no-one<br>
prevents you from implementing a bytecode interpreter on top of it.<br>
But this is beyond the scope of current project. :)<br>
- there is no primitives nor need in writing external code in C (or in<br>
any other statically typed language). A primitives replaced by native<br>
methods (methods with <native> pragma), by using which you can<br>
implement any low-level behavior.<br>
<br>
- everything (by a 99.9% ;) in system is up to implementor. There
is<br>
a few 'glue' semantics used by compiler, but compiler itself<br>
extensively using static inlining (inlining native methods from<br>
well-known classes such as CompiledMethod/ProtoObject or<br>
StackContext). Memory management/relocation, FFI , a diverse set of<br>
what we currently know as 'privitives' will be implemented in a<br>
system. This opens a potentially huge playground, how system would<br>
look like :)<br>
<br>
- avoid using global state. All state which code can potentially refer<br>
to is placed in literals. There is no difference between native<br>
methods and smalltalk methods in compiled method format. The<br>
difference only how they are compiled. Of course there will be some<br>
global state , i think it would be a single 'lobby' object, which<br>
contains a symbols table (required to support symbols uniqueness<br>
thoughout all system). But anyway, references to it will be possible<br>
only from method literals.<br>
- generated native code are location independent. Since all jumps will<br>
be relative, and all location-dependent stuff are either held in<br>
literals or computed. Therefore a CompiledMethod instances can be<br>
relocated freely in memory (by GC and friends) without any change that<br>
it will cause any harm.<br>
<br>
- compiler translates smalltalk code to a lambda representation. Then<br>
using different transformations it generates a low-level lambdas,<br>
which represent a virtual machine CPU instructions. No AST nor bunch<br>
of different classes to represent semantic elements of code used.<br>
Lambdas all the way down.<br>
<br>
- an object memory model is initially based on Ian's minimal object<br>
system. With some changes.<br>
<br>
You can download a snapshot of project at squeaksource:<br>
</font></tt><a href=http://www.squeaksource.com/CorruptVM><tt><font size=2>http://www.squeaksource.com/CorruptVM<br>
<br>
What is currently should work:<br>
<br>
CVMachineSimulator bootstrap -- bootstrap a object memory for simulation<br>
CVSimulationTests run -- run different tests on boostrapped object memory<br>
<br>
There are also an initial implementation of translating to native code<br>
using Exupery (you need to load Exupery for that).<br>
Do it:<br>
CVExuperyCompiler test inspect<br>
<br>
<br>
I am currently open for suggestions and advices or discussion in how<br>
is better to implement system based on such design.<br>
Would be glad to read your comments.<br>
<br>
There is also a wiki page of project:<br>
</font></tt><a href=http://wiki.squeak.org/squeak/6041><tt><font size=2>http://wiki.squeak.org/squeak/6041<br>
<br>
-- <br>
Best regards,<br>
Igor Stasenko AKA sig.<br>
<br>
</font></tt></a></a>
<br>