RE: Activity
"Jonathan Bachrach" <[email protected]> Tue, 2 Aug 2005 18:54:42 -0400
| Newsgroups | gmane.comp.lang.goo.general |
|---|---|
| Message-ID | <[email protected]> |
I have to say that you caught me at a good time. I've been experimenting with both multimedia apps written in C and experimental languages for new paradigms of computation. I intentionally departed from goo to free myself to concentrate on the tasks at hand and to not be unduly biased. I am now ready to integrate the results of my research back into goo. I have included specific comments below: > -----Original Message----- > From: [email protected] [mailto:googoogaga- > [email protected]] On Behalf Of Scott Graham > Sent: Tuesday, August 02, 2005 2:47 PM > To: [email protected] > Subject: Re: [Googoogaga] 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 > much > > 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. I'm very excited about getting goo apps to run on xbox/psp etc! What does someone need to be able to develop code for such a system? How would I get started? > 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. This is the way it works right now. You can create a very small system without the full c compiler in the runtime with only the interpreter instead. > 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). Yes this is true. > > > 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. > > > > This could be done and is desirable. Not sure what the plan would be. > Goo > > 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? I really want to resurrect goo and fold in some changes that never got released. > > > And finally, I'd like to see a less restrictive license (at least LGPL > > > ... > > > > I'm open to all of that. It's really just about getting MIT lawyers to > do > > 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. Any software work that I do on MIT's time must be released by permission of MIT. I got "them" to agree to release goo under GPL. I chose GPL. I could have chosen another license. I would just need to get them to change the licensing. > 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 _______________________________________________ Googoogaga mailing list [email protected] https://lists.csail.mit.edu/mailman/listinfo/googoogaga