[self-interest] Self on Linux

Jecel Assumpcao Jr jecel at lsi.usp.br
Tue Jan 19 16:20:27 UTC 1999


Gordon at Cichon.de wrote:
> I am so terribly fed up with C++, I really would like to
> write real programs in a better programming language.
> Fortunately, the source code of Self is publicly available :-)

Good choice!

> I just started a Linux/i386 port of Self 4.0.

This is an interesting trend. In the mid 90s, there were several people
working on Self-like languages - Self itself was considered to be some
kind of ideal that could not be reached by mere mortals, or like a good
idea that could be greatly improved upon, depending on the particular
group. Now, almost four years after the release of Self 4.0, the
language seems both good enough and implementable so that there are
at least six groups working to port it!

> I still have some doubts whether I understand the Sparc stack
> frame right. I was not able to obtain a Sparc documentation on
> the web, and I still do not understand, when and where Sparc
> saves its register windows on the stack. Especially, there are
> 24 entries reserved on the stack for the register window while
> there are only 16 registers saved to my knowledge (8 incoming
> + 8 local). Is anybody out there who could help me with the
> details of Sparc register window architecture?

The Sparc references that Jochen Schneider gave will probably really
help, here. But, just to give you a hint, the SAVE instruction
switches to the next register window after a call while the RESTORE
instruction switches back to the previous window before a return.
But the number of register windows is limited (and varies between
different Sparc implementations), so either a SAVE or RESTORE
instruction might cause a trap indicating an invalid window. The
trap will save the registers of some other window to the actual
memory stack and mark this window as valid so the SAVE can work.
So the code for moving registers to/from memory is hidden in the
trap.

"grepping" through the source code, I didn't find any references to
24 reserved entries.

> I think, it is also going to be hard work to change SIC to
> a two-address machine with little registers. It would be nice
> to switch off SIC completely until NIC runs. Unfortunately
> the ┬┤SIC_COMPILER┬┤ define does not work well for this purpose
> and leaves a lot undefined symbols especially in recompiler.c.
> Well, I think that even a not register optimized SIC that does
> inlining would still be nice to run Self on i386.

You can leave the SIC in but set things up so that it is never
invoked. Hmmm... I can't seem to find out how you would do that
(_PrintOptionPrimitives didn't help at all).

Given the speed of current Intel machines, Self would probably run
acceptably even with only the NIC. And while it is true that the
SIC was designed with lots of registers in mind, I am sure that it
could be adapted to the x86 since the gcc was too.

Some background for those reading this who aren't familiar with the
Self implementation: all code is compiled to native Sparc machine
language the first time it is invoked by the Non Inlining Compiler
(NIC). This compiler embeds some counters in this code, and if it
is detected that this method is critical to system performance, then
it is recompiled by the slower (but better) Simple Inlining Compiler
(SIC). This allows the system to remain highly interactive while still
generating high quality code where it matters most. There are a lot
of papers about this.

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