Re: Activity

Warning: a bit long-winded...

> > I'd like to be able to use goo on an embedded system. Ideally, I'd
> > ...
> What sort of embedded platform are you thinking of?  In particular, how m=
uch
> memory would your target system have?  I am also thinking of embedded
> systems.  Currently goo doesn't have memory/code space as its primary
> implementation goal.  I was thinking about doing an extremely small
> footprint VM implementation combined with a JIT.

My "real job" is a console game programmer. 99% of console games are
written entirely in C/C++, and having made games that way for the last
6-7 years, I strongly believe the time for that is over. I'd love to
bring goo up on an Xbox or PSP. These are probably larger embedded
systems than you were thinking of. The "embeddedness" of game consoles
is: limited memory, though a reasonable amount (~16-64meg, and larger
now), no virtual memory, soft real time constraints (especially for
GC), multiple hardware threads, and the general unavailability of TTY
and some general posix-y things (environment variables, etc.). There's
also the question of targetting a variety of different processors: at
least PPC, x86, MIPS. Anyhow, I'm not hoping you'll magically sort
through all those problems, but I think goo would be the perfect thing
to build on/around for a language that's very suitable for game
programming.

The JIT sounds like a neat/fun idea, though possibly quite a lot of
work, depending on what hardware it was to run on. The small footprint
VM (sans JIT) could certainly be very useful in a variety of
situations though. Personally, I'd like to see just two (possibly
simpler) levels: the straight interpreted/VM version, and the
compiled-through-C version. As long as both the interpreter and the
compiled version have the same semantics, and the interpreter
"overrides" and interacts with the compiled code cleanly, this seems
like the best of both worlds. Generally, the workflow could be compile
everything through C, then iterate using the interpreter
(re-re-defining methods, etc.), and when you take a break, or need to
restart the application, recompile all to C and start over. I'm
assuming that the C compiler can do crazy hardware-specific
optimizations that goo can then get relatively for free. (Is that
actually true? I'm not sure how amenable to optimization the goo->c
code is for the C compiler).

> > A related request, that's possibly the first step in that direction:
> > clearly defining all the interfaces to the system, and assuming less
> > availability of various posix, etc. functions. Being able
> > enable/disable: bignums, tty, stdio. This would also help with at
> > least minimal ports to other (possibly smaller/simpler) OSs.
>=20
> This could be done and is desirable.  Not sure what the plan would be.  G=
oo
> can definitely be run without bignums and the rest.  It's really about
> designing and teasing out the modules.

I can certainly look into this. I don't know too much about the
internals of goo at this point, but it doesn't seem too big and scary
:-), so I'm sure I could make a first attempt at factoring out the
things that I'm concerned about (at least as a test). Is the released
0.155 what I should work against?

> > And finally, I'd like to see a less restrictive license (at least LGPL
> > ...
>=20
> I'm open to all of that.  It's really just about getting MIT lawyers to d=
o
> something.

Ah, OK. I didn't realize that had to involve lawyers. The license
commonly known as the "MIT License" would be perfect, though obviously
I have no idea if your institution has deprecated or otherwise doesn't
like that license. Perhaps it's more permissive than you want too.

Anyway, thanks for your comments. I hope you can find time to continue
to work on goo.

scott

_______________________________________________
Googoogaga mailing list
[email protected]
https://lists.csail.mit.edu/mailman/listinfo/googoogaga