[self-interest] Re: desnarfing tinySelf

Jecel Assumpcao Jr jecel at lsi.usp.br
Tue Apr 20 21:22:17 UTC 1999

Jose' B. Garcia Perez-Schofield wrote:
> > [magical steps for generating file that boots on a PC]
> >
>         Excuseme, but this image file contains an executable Self for the
> arquitecture contained into X86 cpuDescription, or a self program ?
> I have not understand it totally.

Sorry - the way I explained it even I couldn't understand it :-)

In Smalltalk you needed four files to get your work done:

  1) the virtual machine: an executable specific to the computer
     you wanted to run Smalltalk on (squeak.exe, for example)

  2) the image: information about all objects in memory at a given
     time. Includes method objects with bytecodes. This file can
     be saved on one machine and read on a very different one (by
     a different virtual machine, of course!) with no problems if
     a few issues (like big-endian/little-endian) are taken care of

  3) the sources: this is just text (though it might be compressed in
     some way) of the Smalltalk code represented by the bytecode
     methods in the image.

  4) the changes file: just like the sources file but includes the
     text for the methods that have changed since the source file
     was last updated

Files 2,3 and 4 are very tightly coupled and using different versions
of them will cause nasty things to happen. The version of 1 should
also be consistent with the other files, but this isn't as critical
if some care is taken (like in the Squeak project).

In theory, 3 and 4 didn't have to be separate files, though
this "poor man's logging file system" does enhance safety. And
the reason why they were separate from 2 is that Smalltalk evolved
on 16 bit machines with small main memories. With today's technology,
it makes more sense to combine 2, 3 and 4 into a single "Snapshot"
file like Self did.

The Self virtual machine, unlike many Smalltalk's, uses a compiler
and produces executable code. Self allows this code to be saved
in the Snapshot so you don't have to compile it again the next time
you run your application. So now 2 includes the data for all objects,
the methods in bytecode form, all the sources and some methods in
Sparc machine language form. This last item is optional and you can
omit it to get a smaller Snapshot file (the compiler will just
recreate all this the next time you run - no big deal). As you might
imagine, having this machine code in the Snapshot isn't good for
cross-platform compatibility, but since it is optional it would just
be annoying for a X86 Linux Self to open a Sparc Snapshot and find
a lot of stuff it didn't understand in there. Just throw it away and
recompile it.

One way to avoid having version problems would be to simple include
a copy of the virtual machine in the Snapshot! Then you are down to
a single executable file that simply runs. This would seem like a
really bad idea when you consider that each platform needs a separate
virtual machine. You could include all of them in each Snapshot and
either find a clever way to have each platform find the VM it needs
in the file or else you can have a very tiny executable on each
platform that does this for you. This last option brings us back
to the two file system, but the tiny boot program would be much more
stable (one version forever...) than the virtual machine.

So the file I proposed generating from within tinySelf 2 inside
Self 4.0 was a combination virtual machine/snapshot that can be
directly (or nearly so) executed in Intel Linux. I won't complicate
things by mentioning that I want to break up this huge 1,2,3,4 file
into many small ones :-)

> > [Self compiler in Self]
>         And what about the performance ?
>         A compiler running on top of Self 4.0 will not be precisely a
> sprinter ;-).

Sure it will - Self compiled code runs nearly as fast as C and as
the compiler is improved it will recompile itself to run faster!

>         Sun Self have strong processor and memory requierements; it not
> runs in every machine.

It does need a lot of memory, but I have used Self on very old machines
and as long as there is enough memory it is very usable. I did most of
my Self 4 programming on a Sparc 20, which is only as fast as a
100Mhz 486...

-- Jecel

eGroup home: http://www.eGroups.com/list/self-interest
Free Web-based e-mail groups by eGroups.com

More information about the Self-interest mailing list