It would be great to also add this algorithm into +poseAsClass: and possibly category handling, since that would allow to have posing classes and categories define their own ivars.
-- Saso David Chisnall wrote: > On 3 Jun 2008, at 09:11, Fred Kiefer wrote: > >> I like this whole idea a lot, but we will need a bit more performance >> testing to make sure we understand the consequences. >> >> What I did not quite get is where are we going to store the size of >> the different classes? Perhaps a more detailed outline of the >> algorithm would help here. >> >> Fred > > Each class has an instance_size parameter. This is filled in by the > compiler, which creates the class statically in the data segment. It > also has an array of structures containing the offsets of each > instance variable from the self pointer. My proposal is that the > compiler should be modified so that: > > For all classes which are not base classes, instance_size is set to 0 > - the size of the instance variables added for this class. > The addresses of all instance variables in the metadata structure are > then set to the offset from the start of the new class. i.e. the > first instance variable declared for any class will have offset 0, > irrespective of the size of the superclass. > > The runtime will then be modified so that, on loading a class, it > checks whether instance_size <= 0 (instance size is currently >= > sizeof(id), since it always contains at least the isa pointer). If > so, then it will set instance_size to super_class->instance_size - > instance_size (don't forget, instance_size is negative for classes > supporting non-fragile ivars). It will then add > super_class->instance_size to the offset in every ivar. > > The module load function will then introspect the runtime to get the > offset of each instance variable in the class and store it in a > name-mangled global. I'd like to be able to get it directly from the > metadata structure, but I don't think this is possible (although with > link-time optimisation it might be). > > Anyway, I will try implementing this in the fork of the GNU runtime we > have in the Étoilé repository, and if it seems useful send the patches > upstream. I had a chat with Andrew Pinski a while ago, and he's > (provisionally) willing to accept patches for this but doesn't have > the time to do it himself. > > David > > _______________________________________________ > Discuss-gnustep mailing list > [email protected] > http://lists.gnu.org/mailman/listinfo/discuss-gnustep _______________________________________________ Discuss-gnustep mailing list [email protected] http://lists.gnu.org/mailman/listinfo/discuss-gnustep
