64 bit cleanup completion?
Ian Piumarta
piumarta at speakeasy.net
Sat Apr 22 03:39:25 UTC 2006
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
More information about the Vm-dev
mailing list