[jan_vrany]

[cgittinger]

Oh yes - you are absolutely right in all of your points.
The big obstacle in the way is our old friend, the stc compiler. That one is (still) written using yacc and lex, in C. Therefore, it has very limited chances of doing any real work at compile time - especially, and for this issue relevant: it cannot evaluate any smalltalk. I must admit, that I do have a love/hate relationship to stc; on one hand, its an inflexible beast, written in C. On the other hand, its the one tool which allows for most of ST/X's portability, helps to bootstrap to other architectures and also generates the standAlone dll and exe objects.
We could enhance stc to pass some of the parsed code unevaluated and have the initialize code handle this later, when smalltalk has control. That would mean, that the annotation-contents is passed untranslated by stc to some later stage during the startUp and then compiled by smalltalk (possibly lazily).
However, we have actually stopped further enhancements of stc because we think that its too hard to maintain and needs a replacement:
For quite some time, I have started to work on a new compiler, which uses the same front-end as the bytecode compiler but takes the generated bytecode and generates C from those. It is written in Smalltalk and will need the old stc for bootstrapping. Obviously, it will understand Smalltalk and will be a good basis to implement all of the features you aked for. Right now, I cannot tell you when that will be ready for production - it is in a releatively early stage, and definitely not stable enough for publication. It will also need a different librun, as I plan to generate continuation-capapable C-code (for all those seaside fans). I will keep you informed. Is anyone willing to help working on that ? I could also think about some bachelor/master/diploma themes based on that...

Claus

[jan_vrany]

[cgittinger]

I do have some frontEnds already; so the parser is not the biggest issue at the moment.

The idea is to have multiple frontEnds, generating intermediate code for various backends. I have frontends for ST, JavaScript (and it should also work for things like PHP, Python etc).
The ST frontend's testSuite parses and translates all of the existing smalltalk code.
I wanted to have a Java and C# frontend as well, to be able to suck in lots of existing code. It has alerady been proven (although not finished to product maturity) that Java code can co-exist within a smalltalk image; both by the VisualAge-for-Java guys, and by my own ST-VM integration. The same is true for C#.

I have backends for byteCode (almost complete), direct-C-Code (some) and tree-code (lisp-like).
My far-end goal for the in-image translation actually was to get rid of bytecode, and try tree-code, because I dont see any reason for the jitter to reanalyse the bytecode to find loops and other obvious constructs. Bytecode is a yesterdays solution to a yesterdays problem (small memory). If all of the bytecodes where replaced by treecode, the system would only be a few megabytes larger - who cares these days

I also have a bytecode to C-code translator which is almost finished. It can read all of the existing smalltalk code and generates valid C-code for methods and blocks. I am working on the Init-function code generation and the rest of the infrastructure interfacing to librun. My plan was to generate compatible code first, but migrate to a new librun later. I have also started some little experiments in the jitter area (doing it in smalltalk). Maybe we should merge in the work of the squeak guys (Eliots work and the Exhubery things).

The bytecode-to-c-code translator generates continuation-passing c-code. That means, that it will support seaside, prolog-like backtracking and othr fancy control when finished (Its the same kind of code which is generated by some Lisp and ML systems, which target for C). However, as of today, I do not have runtime support for it. As part of my lectures, some of my students and me developed a self-bootstrapping minimalist lisp engine, which is also able to compile itself and also works with continuation passing. My plan is to bring this (lisp-encoded) VM underneath and use it for both lisp and ST (with a flexible object model which supports both). The big problem with the students is that I got freshmen every other semester, so each time I had to start from scratch with them
The situation will probably be better next year, when I might get both bachelor and master students (its not yet fixed, but likely). I'd really love to continue with that work as a dualistic scheme/ST engine and IDE would definitely be great.

All of this is and has been an idle-cpu-time task of myself, and is not making progress in the speed I would like. So help would really be welcome at many places. I would also get rid of the existing VM and the existing object model, and trade memory usage for flexibility.

So, where do you want to work on ?

Claus

[jan_vrany]

Huh, you did a lot of work already! Nice.

The system you are describing is something I'm dreaming about
(to say truth, many of my ideas are influenced by your post in VW wiki @ uiuc.edu).
Actually, I'm trying to do my PhD in this area.

I did some initial experiments, using SELF as a bootstrap language. I've some
hardcodes AST-based SELF interpreter, initial implementation ObjectMemoryBackend.
(all implemented in St/X cos I don't like to prototype in C
I also created a library for creating AST interpreters with debugging facilities
and created unified debugger, allowing one to debug application consisting of
byte-code based code written in St/X and AST-interpreted DSL code in single environment.

So I definitely would like to cooperate on topics you outlined. It will help me a lot,
since I'm the only one in Czech Rep working in VM area...
Is there any concrete task I can work on?