[self-interest] Re: Self on Linux

Gordon Cichon Gordon at Cichon.de
Mon Feb 8 20:13:10 UTC 1999

Douglas Atique wrote:
> 1) Just out of curiosity: Did you write a new assembler or did you adapt
> gas to be called by the NIC?

I adapted gas :-)

> 2) Cooperation: tell me what you know about the stack and what the problem
> with it is. Maybe this can help me understand it better and help you.

Thank's for your interest :-)
The main problem is still that I don´t know what´s the problem
with it. In the mean time, I found out that the situation is
actually different from Sparc. Sparc obviously stores its saved
registers (incoming and local) one frame above than i386. On
Sparc, FP points to extra incoming arguments, SP points to extra
outgoing arguments, and the registers are going to be saved by
the called function at to topmost end of the newly created frame.
These three form a linked list:
new stack frame -> SP -> FP.
Since the size of the stack frame of the called function is not
known in advance, the entire stack has to be searched.
On i386, the situation is different in two aspects:
1) The registers are saved at the bottommost end of the newly
   created stack frame and can therefore be accessed using SP.
   So, there are only two pointers involved, namely SP and FP,
   that can be precomputedat call time. Since Self´s multithreading
   is not as preemtive as I considered it in the first place, 
   growing and shrinking stack frames are not as interfering as
   I thought.
2) The second difference is about the interface between Self and
   C code. In i386´s calling convention, the called function does 
   not have to save registers on the stack. The garbage collector
   would therefore not find them when traversing the stack. The
   integration of Self with C code on the stack can therefore not
   be as seemless as I originally wanted it.

I am considering intoducing a kind of `dummy' stack frame for 
interfacing with C that contains the saved registers at a
predictable position, and that is maybe marked with a special
return address. Outgoing arguments have also to be copied into
this frame. (Should solve problem #2)

For problem #1, I have difficulties to predict what happens
if I change the stuff in there. The implementation of classes
`frame' and `halfFrame' is influenced by `process.c', `stack.c',
and `frame.c'. And still, there a many other places around that
access frames directly. I thought that maybe the frame chaining
behavior could be changed with the constant `localsInBottomHalfFrame', 
unfortunately the system broke when I changed the value of it.
I do not want to break the garbage collector under any circumstances
because debugging it would be very tedious.

So, my question is:
What has to be done to adapt the system to the new stack


Gordon Cichon          email: Gordon at Cichon.de

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