I've just started work on compiling blocks but unfortunately there isn't a spare slot in BlockContexts to hold a pointer to the natively compiled code so I'm thinking about creating context classes for Exupery.
The new contexts will be removed when Exupery is shutdown or Exupery's code cache is initialised because they will hold pointers to compiled code which isn't saved with the image. However they will need a compact class number so they can be checked for. This is important because the GC needs to check if an object is a context so it can deal with the stack. If I use a compact class then the extra check will just be an extra integer comparison. I'll probably swap the position of the caller and the instruction pointer for Exupery's contexts. This way an integer check of either position will indicate if it's an Exupery compiled context or an interpreted context. Exupery's instruction pointers are pointers to compiled code tagged as integers. The caller or sender slot should always be a pointer object not a SmallInteger while both Exupery instruction pointers and interpreted instruction pointers are always SmallIntegers. Would checking the instruction pointers size be more sensible? In practise it would be safe but there's a risk that the code cache might be allocated at memory location 0 on some platforms. I'll need to use my own contexts for natively compiled methods as well once Exupery starts inlining methods. This is so that image level code will be able to hide the inlining or de-inline if necessary (say when single stepping in the debugger). Any objections? Bryce _______________________________________________ Exupery mailing list [email protected] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/exupery
