[self-interest] Problem running Self4.1.2 UI on sparc

[Jecel Assumpcao Jr]

> Wich version of SunOS are you running ?

Solaris 2.6 (also known as SunOS 5.6).

> Does it work for you: 'smallUI2.self' _RunScript 
> from an empty world ?

No. After solving some directory problems (setting SELF_WORKING_DIR
correctly), I got this error:

  Failed to read: xlib from: ui1.   Error: ENOENT

right after it had read in 'objects/core/int32and64.self'. This is due
to the "bootstrap read: 'xlib' From: 'ui1'" line in 'smallUI2.self',
but the 'xlib.self' file is actually in the subdirectory 'graphics'.
Fixing this and the following line ('spline.self' is also in
'graphics') allowed me to load all the way to 'ui2/morphLib.self' where
I got a VM error saying it couldn't construct and object literal.
Hmmm... it tried to send a message to fontSpec that isn't defined.
Since that also seems to be in the 'graphics' directory, I replaced the
'xlib' and 'spline' lines above with 'allGraphics'. Now everything
loads, though it takes a very long time to refill the module cache.
Next time I'll do "_Spy: true" before starting these things. Nothing
happened after I got to the self prompt, so I tried "desktop go" and
still nothing happened. "desktop worlds size" is 0, so everything seems
normal. So "desktop openNewWorld" finally gets some result!

So now the answer is yes. But of course, everything that was "hand
crafted" in the Demo.snap world (like all the texts and tutorials) are
not present here. This is more like BareBones.snap without even the
trash can. Interesting - opening the spy I can see the the "old space"
in memory is broken up into four little pieces, unlike what you get
when you start up from a snapshot.

> btw. how are related the performances (roughly) of a sparc old 4 years,
> a new sparc today and a pentium III 450. (and where fits in this scale an ultrastation-2)
> ?

Having run Squeak on several different machines, I would say an old
Sparcstation 20 is like a fast 486 100 MHz machine while my newer
Ultra 5 is like a Pentium 200 Mhz.

> Is it possible that the self on sparc would be always faster than on
> PC because of register stack framing and tagged pointer arithmetic ?

In his thesis Urs Hölzle concluded that these feature didn't help Self
very much. The most important factor by far was the instruction cache
size (page 104). Of course, he only tested the "old" register windows
on a Sparcstation 2 running SunOS 4.1.3 which had a huge overhead
(which is supposed to be fixed in the newer Ultra machines).

> How is the felling running the Self GUI on a clean (sparc) machine,
> without other load, is it smooth?

Under these conditions I like to demo drawing programs and animations.
Self slows down considerably when memory is low and it starts to swap,
so killing off a few copies of Netscape really helps...

> Are you porting the sunlabs sources to PC ?
> Gordon's port was based on the plain 4.0 sources if I remember well.
> Does that mean that a new port must be started with the 4.1.2 since
> David has inproved the portability framework ?
> (or it is already started?)

Gordon released a partial port of Self 4.0 in 1999, and an attempt to
combine this with David's 4.1 (not 4.1.2, I think) work earlier this
year. This is what I have been looking at (I haven't started changing
it yet).

> Does this TWAINS primitive depend only on the VM (lighweight threads) or
> also on the
> OS. It is possible that the VM does not work well with a newer version
> of SunOS (5.6)?

TWAINS only need the OS to have some kind of interrupt mechanism. David
Ungar mentioned the problems he is having with this in MacOS X in
another message. The current VM *only* works with SunOS 5.6 or newer.
It does not run on SunOS 5.5. The older VM works fine on both versions
of the OS.

> But this seems strange to me because I have heard that Self implements
> lightweight threads
> using stack overflow polling at the beginning of every method and that
> all is controlled by the VM.

Exactly - it is all implemented in Self itself and not depedent on the
OS. Stack overflows are compiled into the code and when the OS tries to
interrupt Self is changes the stack pointer so that the checks will
fail. Then the handler sees if it really was a stack overflow or some
other interruption (in which case it restores the stack).

The idea behind all this is that interrupts can only happen (as far as
the Self code is concerned) at certain "safe points" and not between
two arbitrary Sparc instructions. That means that only at these safe
points must the stack and memory be "by the book" so that the garbage
collection and other system routines can make sense of them. At other
times they can be "messed up" if that helps things to go faster. This
will allow my Tachyon processor (which has Self as its machine
language) to eliminate a lot of complex circuits that are needed in the
Transmeta Crusoe chips (and which they have patented, in any case).

-- Jecel