[self-interest] Self on Linux

[Gordon Cichon]

"Jose' B. Garcia Perez-Schofield" wrote:

> > All:
> >
> > Do I understand this correctly:  Is Self 4 available on Linux?
> >
> >
> >
>         Well.. I am attemping to install Self for Linux, yes, but it is a
> limited version, it isn't (I think) the complete 4 version.
>         (If you are interested in the graphic world, I'm afraid that it
> is not released yet.)

It is the complete Self 4.0 release. It contains the entire Self code
along with an incomplete port of the machine specific C code (the vm).
There is already a new NIC code generator and an assembler for i386.
What´s still missing to run all the Self code is an apdation of the
stack frame to something like a "non-register-window" architecture.
If it were done, the Self user interface should run on top of it.
The OS is almost the same.

Unfortunately, I have quite a lot of work to do at the moment, so I
cannot go so deeply into debugging the stuff as I could in January.
I already tried it several Saturdays, but one day is too short to keep
the overview over all the stuff that depends on each other. The stack
frame management is  the least centralized component of the
whole system: spread over several modules (stack, frame, process, ...)
and highly specific to Sparc's register windows. It's likely to take a
week to check every single machine instruction that gets executed
for such a simple thing like `[1] value'.

There are two important problems to be solved when switching from
Sparc`s register windows to a `normal' stack:
1) Sparc saves the registers of a calling procedure at the top of
a new stack frame. i386 work more like `first: save old registers,
second: make room for new variables' while Sparc appears to
allocate its temporary space before saving its registers.
2) On Sparc, the locations where registers are to be saved are fixed.
On i386, a procedure can decide by itself if and where to store
registers on invocation. This affects the way Self code interacts
with C code. It happens quite often that C code calls Self code and
vice versa while the garbage collector must be able to walk the stack
and find register contents of its Self code.

There are two ways to solve this problem:
1) Stick to C calling convention for Self code, remove callee
procedure searching for saved register access (the saved
registers can then be accessed with a negative offset from the
saved stack pointer), and introduce dummy stack frames when
calling C from Self to have fixed positions of saved registers.
2) Make Self code work with Sparc stack format, i.e. save registers
on top of temp space of called procedure.

So folks, that's the job to do! You can either wait for my next
vacation somewhere next year or try it by yourself.

Well, the guy who first evaluates `[1] value' on this gets
the `Gordon Coolness Award' endowed with a chest of
best bavarian beer. Is this a word?

Gordon.

--
----------------------------------------------------
Gordon Cichon          email: Gordon at Cichon.de
Germany




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