Re: Why are you using Smalltalk instead of Assembler???

news.t-online.de schrieb:
Hi Guido,

thanks for referring my work here.
Indeed a big part of our work is going into the interactive Assembler which we use to develop our VM.
So one could ask why we develop an Assmebler to create a Smalltalk-VM.
Mainly because of be able to debug on the VM-Level and to see Smalltalk-objects.

By my estimation thats very much ahead of Microsofts .NET. .NET has got so many layers, intermediate languages, .... which makes the giant overhead and that's what causes crashes. It's completely impossible to run Vista without internal crashes, which are well hidden by Microsoft. They have, due to instabilities, the core divided up into peaches of small demons, which are observed and restarted, in the case of a hangup. In former times this was called "Dr. Watson" or "bluescreen". That's what the former chief architect of microsoft meant with: "it's impossible to bring Vista project to success" - he got fired.

To work with Smalltalk on the
Assembly level gave us deep in sight what to optimize and over time we got a real fast Smalltalk.

That's, what makes an application rockstable in the end. The *possibility* of being able to *control* all layers of software.

Message-sends are optimized: A message send is just a call to the jitted method. The function itself checks whether the receiver´s class matches ( a compare with the MDA with a constant- which is one assembly statement ) and if not calls a vm-function to retrieve the right method from cache or the class-hierarchy - and patches the Assembler call with the right address.

How can i imagine that? Dynamic binding - for me - seems a little bit more complicated: One routine for sorting, several different arrays (float, string, integer, composite). Late binding, how do you succeed in this, with just one compare?

this is the dynamic-binding mechasimn. This message-send mechansism can be further optimized by generatng multiple versions of the code with different receivers of message-sends. These can be done at a source-annotation level when creating Smalltalk-Libraries.
To support optimization the VM can generate statistics of patching frequencies.

What do you mean by this?

Another big area of optimization is garbage collection or better avoidance of garbage collection.
A clever handling of TLS in the VM creates "0 overhead" for multithreaded smalltalk programs which runs as fast as their C-counterparts.

green threads or user-threads? How many cpu's? How big is the RAM footprint?

A thing which I often miss in HLL´s is that the lowest level details are hidden, not documented or otherwise not accessible.

I hate that. I feel helpless without microsoft GOLD support, which is about 20.000 bucks/year still?

This makes it impossible to create the most efficient programs.

efficency - have you read about the boehm-weiss Garbage collector?

*** just some remarks from me inline,

with best regards, Frank Lesser
....
*****
the actual size of the Development-VM on Windows is 120K.
if the JIT-compiler the Image-save-primitives Profiling and debugging primitives/functions are taken out
and various other things necessary only during development the VM
comes down today to 40K.
******

oh, ***! 40K even!!!!!!!!!! Don't you think, you will have to spend some time into more "code optimisations"? ;-)

Very strange for me is, that this interpreted smalltalk engine is as fast like "C" compiled. You even may inline your own assember code.

LSWVST is not interpreted. The Bytecode is JIT translated before it is executed.
It is also possible to pre-jit the code that is put in a Smalltalk-Link-Library. This makes to libraries much bigger but creates
code which is more difficult to reverse engineer because the byte-code can be entirely abandoned.
Further optimizations are possible so that pre-jit boils down to a true compile of Smalltalk
into native assembly-code.
*****

Yes, for me even the G++ is still an interpreter. I think we are both right, when we simply say - Is's some sort of "interpiler" of "compreter". "Interpilation" ;-)

As former 8051 xxx microcontroler programmer i would not hesitate to change directly to frank lesser's smalltalk engine: "LSWVST"!

*****
we had plans to publish in 2008. However after the latest "Dolphin event" we rethink our plans

I really think, that your design of a smalltalk engine is almost perfect and straight forward, like no other smalltalk engine. And i think, also much faster, than all other smalltalk VM - say: One magnitude?

and maybe we adopt our VM for Ruby and abandon the plan of publishing our Smalltalk.

You already have read this? http://chadfowler.com/sts07.pdf

I am really convinced, that your VM can execute ruby and smalltalk at the same time ...

..NET needs type declaration, has no real dynamic binding. See S# - Peace of crap, unusable - a marketing gag. Once again by microsoft! No block closures, late binding ... useless. Ruby/Smalltalk code will never run perfectly on .NET

Have fun, Guido Stepken
.