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

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. 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.
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.
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.
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.
A thing which I often miss in HLL´s is that the lowest level details are
hidden, not documented or otherwise not accessible.
This makes it impossible to create the most efficient programs.


*** just some remarks from me inline,

with best regards, Frank Lesser


"Guido Stepken" <stepken@xxxxxx> schrieb im Newsbeitrag
news:fea1p5$2c1$03$1@xxxxxxxxxxxxxxxxxxxx
Victor Smootbank schrieb:
The big problem of today's computer industry is that
programmers are using crap languages such as Smalltalk,
C++ and Delphi and the results are crappy programs that
are mega-slow on a 3 Ghz PC.

Back in the 80s, programmers used Assembler to fit great
programs into the 64K of a C64 and most 80s computers
are faster than crap PCs with crap like Linux or Windows,
just because the old programs were written in Assembler.

So better give up these crappy programming languages
and start learning Assembler!!!


So you may start here:

http://www.lesser-software.com/en/flavours/frames/default.htm

You get a smalltalk engine with blockclosures, a well done very complete
library consisting of 20.000 classes, a IDE, GUI classes, a debugger, a
symbolic debugger at assembler level, so you can see your smalltalk
programs running on assembler level. It leaves even a very small footprint
in RAM. So no problem to let it even run on a via c3 with less than
32kbyte!!! RAM and less than 1 watt power consumation.

*****
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.
******
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.
*****


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 and maybe we adopt our VM for Ruby and abandon the plan of
publishing our Smalltalk.

Have fun, Guido Stepken


.

Relevant Pages

  • Re: Why are you using Smalltalk instead of Assembler???
    ... Indeed a big part of our work is going into the interactive Assembler which we use to develop our VM. ... That's what the former chief architect of microsoft meant with: "it's impossible to bring Vista project to success" - he got fired. ... A clever handling of TLS in the VM creates "0 overhead" for multithreaded smalltalk programs which runs as fast as their C-counterparts. ... I really think, that your design of a smalltalk engine is almost perfect and straight forward, like no other smalltalk engine. ...
    (comp.lang.smalltalk)
  • Re: Why are you using Smalltalk instead of Assembler???
    ... Indeed a big part of our work is going into the interactive Assembler ... got a real fast Smalltalk. ... course) .It can be controlled by annotated compilation ... Squeaks Exupery is a way to accelerate slow Squeak code. ...
    (comp.lang.smalltalk)
  • Re: VW 7.5 behavior while dragging a window on Windows XP
    ... It was years before I even knew there was such a thing as Smalltalk; ... Maybe something like the recent "Assembler in Smalltalk" ... flow to the strange organic flow of Smalltalk and be thankful there ...
    (comp.lang.smalltalk)
  • Re: Why are you using Smalltalk instead of Assembler???
    ... Indeed a big part of our work is going into the interactive Assembler which we use to develop our VM. ... Assembly level gave us deep in sight what to optimize and over time we got a real fast Smalltalk. ... Once a Smalltalk program needs to be optimized one need information where optimization should take place. ... Squeaks Exupery is a way to accelerate slow Squeak code. ...
    (comp.lang.smalltalk)
  • The Case Against RosAsm (#7) (LONG)
    ... "Branch Displacement Optimization" is one of these ... The first assembler I recall that provided ... when a wanted short jump was longer than required, ...
    (alt.lang.asm)