Minimal images [was: Re: [ANN] Spaghetti Tracer (0.4)]
PhiHo Hoang
phiho.hoang at rogers.com
Mon Nov 4 15:27:23 UTC 2002
Hi Andreas,
> My personal guess is that the critical size
> is somewhere around 100k or so.
> Put that on top of a 100k VM (which is quite reasonable too)
> and you end up at 200k overall.
> Hey, this should run on MSDOS, too ;-)
Please stop teasing ;-)
That cute little gem at under 400K
already gave me a lot of fun.
But of course I woudln't mind a smaller one ;-)
> This would be quite an interesting exercise but it wouldn't help with
> a)-g). There is lots more to running Squeak than the compiler and its
> size isn't actually that bad.
Especially when we have a Jitter.
Theoretically, dynamically jitted byecode
can be executed faster than pre-compiled counterpart.
But C is as portable as Squeak,
especially no such Jitter is now available yet.
So, a CompilerPlugin is very much welcomed ;-)
Cheers,
PhiHo.
P.S: I like to show off your SqueakScript with MobVM.
Is there any chance that you can put up somewhere a version
of SqueakScript with savedWindowSize set to 0 ?
----- Original Message -----
From: "Andreas Raab" <Andreas.Raab at gmx.de>
To: <squeak-dev at lists.squeakfoundation.org>
Sent: Monday, November 04, 2002 10:36 AM
Subject: RE: Minimal images [was: Re: [ANN] Spaghetti Tracer (0.4)]
> Dan,
>
> > This is an interesting question. I've been thinking about it
> > recently while contemplating the ST72 and ST76 kernels (which
> > are both under 100k of source).
>
> It's relatively simple to make a rough cut at 300-400k in Squeak "as a
> useful small system", e.g., without doing a lot of careful crafting and
> still be able to do about everything you can imagine. At this size you
> end up with basically the following stuff:
> a) Kernel (Object, Boolean, Behavior, Class etc)
> b) Processes (Process, Delay, ProcessorScheduler etc)
> c) Execution (CompiledMethod, Contexts, Exceptions)
> d) Magnitudes
> e) Collections (the basic ones; String, BA, Set, Dict, Array, OC etc)
> f) Streams (the basic internal ones)
> g) Files (directories, streams)
> h) Compiler
>
> With the above, you are actually able to have a cross-platform Squeak
> with a quite reasonable size and no limits of what you can do. I think
> it'd be much harder to get any less than that - if you look at the above
> everything from a) to e) is pretty much required and only very careful
> crafting could remove any of these. The best additional candidates would
> probably be g) and h) by which you'd give up cross-platform and the
> ability to "get more" into Squeak (which might be handled by a compiled
> byte code loader). There are probably more support methods that could be
> removed once those are gone but that again would require very careful
> preparation in order to get to this point. My personal guess is that the
> critical size is somewhere around 100k or so. Put that on top of a 100k
> VM (which is quite reasonable too) and you end up at 200k overall. Hey,
> this should run on MSDOS, too ;-)
>
> > I can imagine a source-only "image" that could be executed by
> > a VM that did dynamic translation (into bytecodes or beyond).
> > This relieves the need for a compiler in the image (other
> > than something that just adds new source to a method
> > dictionary (or simple list!)). I think the essence that is
> > required of a minimal "complete" image is just enough to make
> > the source code meaningful, not necessarily efficient.
>
> This would be quite an interesting exercise but it wouldn't help with
> a)-g). There is lots more to running Squeak than the compiler and its
> size isn't actually that bad.
>
> Cheers,
> - Andreas
>
>
More information about the Squeak-dev
mailing list
|