Bryce Kampjes <bryce at kampjes.demon.co.uk> wrote:
> Daniel Vainsencher writes:
>  > Bryce Kampjes <bryce at kampjes.demon.co.uk> wrote:
>  > > Currently I only target x86 on Linux. It shouldn't be hard to extend
>  > > both to other operating systems and also to other CPUs.
>  > 
>  > Perfect on both counts - that's what I use :-)
>  > <SNIP>
>  > I'll tell you one thing that sounds to me like it might be both useful
>  > and relatively easy to improve on - running the simulator. Since it's
>  > actually Slang (no dynamic sends), it's already a subset of the full
>  > Smalltalk problem (project 1.5?), and since it's currently either
>  > compiled externally (clumsy) or interpreted as full Smalltalk
>  > (relatively slow), you might make it more easily useful.
>  > 
>  > If the simulator was fast enough to comfortably run regular size images,
>  > I guess people would use it more to learn about/debug problem images,
>  > and study the VM. Oh, we need to fix it in the image, too, but Craig's
>  > doing that...
> 
> Interesting. I'm not sure if using an alpha compiler is going to help
> people learn about the VM. If something works strangely what part of
> the system do you blame?
Well, at the beginning, it will mostly help you test your compiler. Then
it will gradually move to helping other people. But that's as it should
be :-)

> The simulator is probably integer/symbol heavy so it should look
> similar to my compiler. Besides that special handling of sends to self
> would help more for the simulated VM than for normal code.
I agree - it's definitely not the same problem as compiling full
Smalltalk. Maybe it's not even a subproblem. But it's a somewhat useful
problem that has much in common with it, and will test your compiler
with a non-trivial piece of code.

>  > > I don't want to start trying to speed up sends until after
>  > > I've got useful byte code speed ups.
>  > Just curious - why? to partition it more clearly?
> 
> I'm trying to carve out the smallest useful project. 
[snip] yes of course. But I assume you'll create a
correct-but-unoptimized-at-all version first. At which point, is there
any reason to prefer byte code speedups over sends? coming to think
about it, one reason might be is that the most common things have been
optimized by making them into bytecodes already, so bytecodes hold a lot
of the execution time.

Well, have fun :-)

Daniel