Thanks for a great answer. So, for question 1, the overhead is not really big.
For question 2: What I don't get is where is the Smalltalk image? The traditional way of coding in Smalltalk is towards a live system. In your description, the result is like any compiled language, right? In that case, much of the beauty of Smalltalk disapears. On Thu, Apr 29, 2010 at 13:26, David Chisnall <[email protected]> wrote: > Hi Alex, > > On 29 Apr 2010, at 11:40, Alex Schenkman wrote: > > > 1) What are the minimum resources needed for the ObjC runtime? (libobjc2 > I guess) > > The runtime's dynamic memory requirements (which, I guess, are what you > care about on an embedded system) are the selector, class, and protocol > tables. These grow based on the number of the classes, selectors, and > protocols in your system. > > If you're really constrained for resources, you might be willing to > sacrifice some introspection metadata. The new ABI no longer requires the > class table for sending class messages and the protocol table is entirely > for introspection. I could relatively easily disable these and create an > embedded profile. Embedded C++ makes similar sacrifices, so we could create > an Embedded Objective-C that doesn't have quite as much introspection > support and shave a few hundred KB off the minimum RAM. > > If you're talking about Smalltalk, then you also need to link in the > LanguageKitRuntime and SmalltalkSupport libraries. Neither of these has a > nontrivial overhead when not in use. They provide things like > Smalltalk-80-like interfaces to some collection classes, support for > non-local returns via the zero-cost exception handling mechanism, and > BigInts for when integer operations overflow. > > > 2) What would the programing workflow be if I developed in Smalltalk? > > compiling smalltalkt code without an image? > > You can use edlc -c to compile a Smalltalk source file to an LLVM bitcode > file. You then need to link all of the resulting files together, along with > the MsgSendSmallInt.bc file, generated when you compile LanguageKit. This > file defines integer operations and the LLVM inliner will inline them all > for you, so 1 + 2 in Smalltalk and C will generate the same code (in theory; > in practice only if the optimizer spots that 1+2 will never overflow a > 31-bit integer). > > You can then use llc to turn the resulting blob of bitcode into assembly, > then into a native binary with your favourite assembler (just passing it to > clang / gcc generally works). > > Alternatively, you can use the JIT and JTL compiler. The JIT has about a > 20MB memory overhead, so it really depends on what you mean by 'embedded'. > If we're talking something like embedded Linux, with 64+MB of RAM, then you > might just be able to squeeze this in. With the JIT+JTL compiler, you just > copy your source files into your bundle, create an LKInfo.plist file > describing them and the frameworks that you need, and then run it with with > edlc -b. The first time you run it, it will be JIT compiled. The second > time, it will use the native version. > > Note that LanguageKit depends on GNUstep (and a little bit of Étoilé), and > GNUstep depends on a vaguely POSIX-like system. > > David > > -- Sent from my Cray X1 > > > _______________________________________________ > Etoile-discuss mailing list > [email protected] > https://mail.gna.org/listinfo/etoile-discuss >
_______________________________________________ Etoile-discuss mailing list [email protected] https://mail.gna.org/listinfo/etoile-discuss
