It's been a while since the 64 bit cleanup work was started and almost as long since anything much was done with it. There are a number of plugins that need some work to get rid of things like cCoerce:to: in favour of oopForPointer: etc.
There are places with #flag: Dan lying around and Dan has expressed a lack of time to do anything with them but a willingness to sit with someone and a beer to explain what he was thinking of. I'm not going to be heading down to silicon valley anytime soon so I certainly can't do that but anyone that can take notes could do it and report back. Volunteers?
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim "Bother" said Pooh, as he flunked the the sobriety test.
On Fri, Apr 21, 2006 at 04:49:01PM -0700, tim Rowledge wrote:
It's been a while since the 64 bit cleanup work was started and almost as long since anything much was done with it. There are a number of plugins that need some work to get rid of things like cCoerce:to: in favour of oopForPointer: etc.
There are places with #flag: Dan lying around and Dan has expressed a lack of time to do anything with them but a willingness to sit with someone and a beer to explain what he was thinking of. I'm not going to be heading down to silicon valley anytime soon so I certainly can't do that but anyone that can take notes could do it and report back. Volunteers?
All we need here is a bit of coordination. Maybe just a swiki page. Way back when, Ian posted a list of "who seems to own what plugin" and status with respect to 64 bit cleanliness. This is a perfectly good starting point if we can just put it on a swiki page and update it from there.
Also needed is a "64 bit Squeak" category for bug tracking on Mantis. There are image *and* VM issues that will need to be resolved, but these are of no interest to most folks with 32 bit Squeak image/VM, and should be separately tracked if anything is going to be done about them.
The original 64-bit motivators (Dan and Ian) did the hard bit. Now all we need is to put a little bit of structure around the follow up tasks. Yes, I will volunteer to pick up one or two tasks, and I'm sure that other folks will do so also.
Dave
p.s. I think this power of two business is a bit over-hyped. The correct machine word size is and always has been 24 bits.
David,
p.s. I think this power of two business is a bit over-hyped. The correct machine word size is and always has been 24 bits.
24? 24???!!! What kind of number is that?!? You can't even fit an entire file name into it (sixbit uppercase ASCII, naturally)!
Noooo.... You need 36 bits, my man. Split down the middle for those ordinary everyday tasks where 18 bit halfwords will do just fine, and in only half the resources too.
A PDP-10 with a KL10 core driving 40 Newbury terminals. That's what Squeak really needs!
(Seriously: AFAIK DEC never finished the design and implementation of the PDP-2 which would have added a 24-bit machine to the most elegant range of CPUs ever designed, IMO. That left either a few 24-bit offerings from Honeywell and the like, or move up to glorious 36-bit PDP-/DECsystem-10s.)
There are places with #flag: Dan lying around and Dan has expressed a lack of time to do anything with them but a willingness to sit with someone and a beer to explain what he was thinking of. I'm not going to be heading down to silicon valley anytime soon so I certainly can't do that but anyone that can take notes could do it and report back. Volunteers?
I could maybe do that next week. But here's what I remember as the last thoughts on the matter:
Plugins: This is mostly going to be tidying up declarations making sure int means machine width, foo * means machine pointer, sqOop means Squeak width pointer and sqInt means integer with same width as sqOop. Gratuitous casts between pointer and int all have to be replaced with appropriate macros/inline functions. (In fact I think all declarations should honestly and truthfully declare precisely the type of their value, including function pointers, with _no_ exceptions. While we're at it, functions returning nothing should be 'void', not 'int'.) Beyond that is hunting down and repairing 32-bit assumptions: divide/multiply by 4, shift by 2, mask by [~]3, etc. LargeIntegerPlugin might have some unique surprises waiting there. The parts of BitBlt and B3D that were never tested (NOTE: these plugins are NOT entirely converted yet) should be tested and repaired where needed. In some cases it's necessary to truncate to 32 bits to avoid unwanted carry out of 32 bits or to force sign extension out of bit 31. IIRC, graphics code had a few very hard to find issues along those lines. This is mostly mindless tedium with the occasional need to think seriously about the right type to use, made even more tedious by having to regenerate the plugin from the image ever few minutes having correlated a C line number with a statement in a Squeak method somewhere.
Taking advantage of 64-bit 'long's: We also discussed the two other obvious changes: SmallIntegers being represented as 63-bits + tag in 64-bit images, and 64-bit Bitmaps storing two 32-bit pixels in each word -- with a couple of additional primitives for 64-bit accesses. It could be the case that many of the 'flag:'s in the image are related to those two issues. Both of these go deep, and profoundly affect things both in the Interpreter and in various plugins. Not to be undertaken lightly.
I know Dan also wanted to clean up the base and method headers, in particular the split fields, in an incompatible image format change. Some 'flag:'s might be attached to those too.
If there was anything else then I'm afraid I can't remember it offhand now.
I think I remember Andreas working on the win32 support code to make it 64-bit clean(er), but I'm not certain.
Frankly I think we'd be making huge progress if we can just get the rest of the plugins to compile and run in both 64- and 32-bits, with sufficient confidence in their correctness to fold them back into the trunk.
I'd be more than happy to set up a repository for 64-bit support code while it's unstable. I could also, in case of dire need, offer accounts on 64-bit hardware for anyone who is eager to work on a particular plugin but has no 64-bit hardware to test their changes.
FWIW: one carrot to dangle in front of people as a motivator is that this work is only half concerned with running 64-bit images. The other half is about running 32-bit images on 64-bit hardware, which more and more people are finding to be a frustrating limitation.
Cheers, Ian
On 21-Apr-06, at 8:39 PM, Ian Piumarta wrote:
David,
p.s. I think this power of two business is a bit over-hyped. The correct machine word size is and always has been 24 bits.
24? 24???!!! What kind of number is that?!? You can't even fit an entire file name into it (sixbit uppercase ASCII, naturally)!
Noooo.... You need 36 bits, my man. Split down the middle for those ordinary everyday tasks where 18 bit halfwords will do just fine, and in only half the resources too.
Fie on that nonsense. What y'need is 33bits. 32 for a decent size integer (who*needs* 64 bit values, anyway) and one bit for a tag. Then you need an asynchronous ARM-like architecture with the TLC (sorta WCS) and floating pint hardware connected to fullspeed mram so that there is no need for data cache. Then you have a few thousand of those in a single machine. Easy. Now gimme One Billion Euros to implement it.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim State-of-the-art: What we could do with enough money.
On Apr 21, 2006, at 8:39 PM, Ian Piumarta wrote:
On Apr 21, 2006, at 4:49 PM, tim Rowledge wrote:
Dan has expressed a lack of time to do anything with them but a willingness to sit with someone and a beer to explain what he was thinking of. I'm not going to be heading down to silicon valley anytime soon so I certainly can't do that but anyone that can take notes could do it and report back. Volunteers?
I could maybe do that next week. But here's what I remember as the last thoughts on the matter:
The only thing Dan wanted to add immediately (without going back and looking at his image) to my recollections was that storing 64-bit words in Bitmap-like objects also required a new format ("indexable 64-bit words only") and class (variableLongWordSubclass:... or something akin).
He also reminded me that I'd been wanting to generalise the code generation such that the choice of image word size could be made at C compile time, rather than when translating the sources. (The various constants appearing by value and that are currently set depending on the word size would instead appear by name in the code, and the build environment would be responsible for switching between 32- or 64-bit definitions for them.) This would allow identical sources to generate all 4 permutations of image width and hardware pointer width.
(The beer in fact turned out to be fish and wine at Joanie's. :)
Cheers, Ian
On Thu, Apr 27, 2006 at 01:03:58AM -0700, Ian Piumarta wrote:
He also reminded me that I'd been wanting to generalise the code generation such that the choice of image word size could be made at C compile time, rather than when translating the sources.
That would be a nice improvement. It would eliminate the need for separate ./src32 and ./src64 directories, and would allow VMMaker to go back to generating the sources to ./src in either case.
Dave
On 27-Apr-06, at 1:03 AM, Ian Piumarta wrote:
He also reminded me that I'd been wanting to generalise the code generation such that the choice of image word size could be made at C compile time, rather than when translating the sources. (The various constants appearing by value and that are currently set depending on the word size would instead appear by name in the code, and the build environment would be responsible for switching between 32- or 64-bit definitions for them.) This would allow identical sources to generate all 4 permutations of image width and hardware pointer width.
This would be very helpful I suspect. Do you a) have time to make those changes yourself, or b) have particular ideas on what to do about them if bar-a.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim There's a guy works down the fish shop swears he's elvish...
Any reply?
Begin forwarded message:
From: tim Rowledge tim@rowledge.org Date: May 2, 2006 5:37:43 PM PDT (CA) To: Ian Piumarta piumarta@speakeasy.net Cc: squeak vm vm-dev@discuss.squeakfoundation.org Subject: Re: 64 bit cleanup completion?
On 27-Apr-06, at 1:03 AM, Ian Piumarta wrote:
He also reminded me that I'd been wanting to generalise the code generation such that the choice of image word size could be made at C compile time, rather than when translating the sources. (The various constants appearing by value and that are currently set depending on the word size would instead appear by name in the code, and the build environment would be responsible for switching between 32- or 64-bit definitions for them.) This would allow identical sources to generate all 4 permutations of image width and hardware pointer width.
This would be very helpful I suspect. Do you a) have time to make those changes yourself, or b) have particular ideas on what to do about them if bar-a.
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim There's a guy works down the fish shop swears he's elvish...
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim "Bollocks," said Pooh being more forthright than usual
vm-dev@lists.squeakfoundation.org
-
David T. Lewis -
Ian Piumarta -
tim Rowledge