[self-interest] dynamic deoptimization (was: ARM?)

Russell Allen mail at russell-allen.com
Tue Dec 13 04:07:24 UTC 2011


  

On 12/12/2011, at 10:13 PM, Thorsten Dittmar wrote: 

>>> For that
reason I thought that the Klein VM would be one of the right steps.
>

>> Maybe in the longer term, I think.
> 
> ok, so in parallel I will
start to search for some research money from the german or european
government for that. That always takes some month, so it will perfectly
address the "long term" aspect ;-)

Sounds good to me. 

>> [Cleaning
the VM] is necessary, otherwise Apple or Ubuntu or GCC will make some
change and we won't be able to compile and that'll be the end. Try
finding money or resources to resurrect a platform that no longer
compiles or runs - it would be impossible. Bitrot is our enemy.
> 
>>
That should also as a side effect give us easier bindings to existing
third party libraries such as QT or SDL, which gives us better and
easier graphics, fonts, sounds, movie playing etc on Linux and Mac,
Libevent which gives us high quality networking etc.
> But all this
needs the groundwork done. 
> So somebody should estimate the effort
resp
> 
>> To be honest I have no idea. My last l
> s…. before the iron
curtain came done...

First step would be to get the VM building cleanly
on the current build setup on the latest MacOS X and Ubuntu and the
latest XCode and GCC. There are some warnings that the compiler is
giving which can be ignored, and some which are about to (or have)
turned into errors as features are deprecated by OSX and/or GCC. Part of
this would be documenting what is needed to build the VM, and how the
build works. 
I think the next step would be to re-engineer the build
system so that the makedeps stage (ie the stuff under $SELF-HOME/bin) is
removed and replaced with something less brittle. From experience I have
found this to be a big barrier to working on the VM, because it
generates various C++ files for me based on the phases of the moon (at
least that's what it feels like). Not all of the stuff under
$SELF-HOME/bin is easily compilable itself, which makes compiling the VM
proper more difficult. This step is tied in with the foreign objects
system used for many primitives. 
I think many of our problems keeping
the VM ticking along come from the complexity of the build and the
source tree, which includes a fair amount of the source code equivalents
of appendixes - they may have had a use at some stage... 
I would say
the third step would be to replace the Self droplet (currently a
compiled AppleScript) so that we can build the Mac OS X VM either as a
commandline or as a proper GUI app - as opposed to the half commandline
half GUI VM we have now. 
I'd be interested in David Ungar's perspective
on this, as he knows the VM source tree better than anyone! 
- Russell 


  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.selflanguage.org/pipermail/self-interest/attachments/20111213/68b32637/attachment.html>


More information about the Self-interest mailing list