From: <pa...@no...> - 2003-09-23 06:41:53
Attachments:
alloc3.diff
|
I have been moving all allocation in the PPC backend into a single macro, modelled on Raymond Toy's work for Sparc, in preparation for porting his Sparc port of gencgc for CMUCL to SBCL/PPC. Attached is a patch with the changes I've made, which so far seem to work (though with rather limited testing as yet). There is one place where this requires using an extra register (allocate-code-object), and one where we sometimes allocate an extra word when consing up bignums. It might be possible to get around those with a sufficiently clever allocation macro. There are also some spots where we could use a generalised with-fixed-allocation where the lowtag is a parameter (the places where previously the :extra argument to pseudo-atomic was used, I think). I'm not sure either of those changes are terribly important, and I'm more inclined to move on to porting gencgc itself. Anyway, any comments on this would be appreciated, and testing on Linux/PPC would be good (I don't have space to install it on my Mac). I suspect cleanups like these would be a good idea for other backends, too, if anyone with access to hardware feels up to it, and that would definitely make porting gencgc to them be easier. The Sparc one in particular should be easy, since we can just steal most of it from CMUCL. :-) |
From: Raymond T. <rt...@ea...> - 2003-09-24 04:11:12
|
pa...@no... wrote: > I have been moving all allocation in the PPC backend into a single > macro, modelled on Raymond Toy's work for Sparc, in preparation for > porting his Sparc port of gencgc for CMUCL to SBCL/PPC. Attached is a > patch with the changes I've made, which so far seem to work (though > with rather limited testing as yet). If it can build itself with these changes, I'd say everything is working just fine! > > There is one place where this requires using an extra register > (allocate-code-object), and one where we sometimes allocate an extra > word when consing up bignums. It might be possible to get around those > with a sufficiently clever allocation macro. For sparc, I decided to ignore the extra word (which only happens when an unsigned-byte 32 needs an extra word to hold the sign), since GC will remove it when the object gets copied. > > There are also some spots where we could use a generalised > with-fixed-allocation where the lowtag is a parameter (the places > where previously the :extra argument to pseudo-atomic was used, I > think). On cmucl/sparc, the :extra arg was the amount of space to allocate in the PA section. This is no longer used in cmucl/sparc. > > I'm not sure either of those changes are terribly important, and I'm > more inclined to move on to porting gencgc itself. Anyway, any I think this is a good place to make a checkpoint before moving on. But that's not my decision. :-) Very good news, indeed! Ray |