Hi Lawson,
Well, the OpenGL plugin itself isnât 64-bit last I checked, and Iâm not
sure what else. Croquet/Cobalt may auto-install stuff that I never noticed.
Thereâs also an issue with Croquet/Cobalt only working properly because
every vlirny generates exactly the same (bit-identical) values in every
possible respect.
Integer handling (and 32-bit floating point) in 32-bit vs 64-bit squeak
may break that. It may be possible to create âproxyâ classes for integers
and floats and use those in both 32-bit and 64-bit Croquet, and allow the
objects on the client-side resolve any oddness, but as it stands now, my
understanding is that a SmallInteger on a 32-bit VM isn't the same as a
SmallInteger on a 64-bit VM and that is an automatic fail for the paradigm
that Croquet is based on, so simply updating Croquet to 64-bit will
automatically make it incompatible with 32-bit Croquet.
Maybe, maybe not. First, Smalltalk's integer arithmetic model is infinite
precision. So integer calculations in 16-bit Smalltalk-80, 32-bit
Smalltalk-80 or 64-bit Smalltalk-80 *should* produce the same results,
except for representation. So while the range of SmallIntegers in each is
different, the results should be equivalent. Hence, provided that the
serialization/deserialization marshaling correctly converts representations
between the systems we should still be able to do computations that appear
to be bit identical in the different width implementations. As an
existence proof, people routinely contribute to Squeak trunk from either
32-bit or 64-bit Spur images according to preference and so far we have not
had a single issue of a commit on a 32-bit system breaking a 64-bit system
or vice verse. Monticello packages committed on one width appear to one
seamlessly loadable on the other width. recently we have also managed to
pull off the same level off compatibility with ImageSegments,
interpretively loading 32-bit segments into a 64-bit system and vice verse.
However, there are clearly things one must not do to preserve the
portability of code across different work widths. One must not write code
such as
result class == SmallFloat64 ifTrue: [#bitch] ifFalse: [#moan]
So as far as Croquet/Cobalt goes, being able to connect 32-bit and 64-bit
systems within the same session will require
- correct marshaling of types affected by word width to map correctly into
the relevant representations
- bit identical implementation of arithmetic (particularly floating point)
across different systems and word widths
- avoiding writing code that responds differently to different
representations
But in building the 32-bit/64-bit our architecture I took care that mapping
from 32-bit I'm ages to 64-bit images is completely automated and
predictable. And, were it useful, one could write a 64-bit to 32-bit image
converter such that 64-bit => 32-bit => 64-bit is idempotent. [One cannot
say that 32-bit => 64-bit => 32-bit is bit identical because even though
the initial and final 32-bit images would have exactly the same objects in
them they could occur in different orders, because in converting a specific
32 to 61 bit LargePositiveInteger or LargeNegativeInteger to a 61-bit
SmallInteger and back, the final 32 to 61 bit LargePositiveInteger or
LargeNegativeInteger would likely end up in a different part of the heap
than it had started in. But one could say that 64-bit => 32-bit => 64-bit
=> 32-bit would produce bit identical 32-bit images]
Which kinda defeats the original "deploy everywhere that Squeak worksâ
philosophy.
It may do; it may not. At Qwaq we insisted that everyone in the same
session use exactly the same build. But I expect that automatically
producing a 64-bit version from a 32-bit build, or vice verse, would indeed
produce compatible images. Of course we won't know for sure until we try
:-)
L
Post by David T. LewisHi Lawson,
Post by LawsonEnglishhttps://blog.krestianstvo.org/en/open-croquet-for-squeak-6/ <
https://blog.krestianstvo.org/en/open-croquet-for-squeak-6/>
Post by David T. LewisPost by LawsonEnglishApple is doing away with ANY support for 32-bit apps and plugins and of
course, Croquet is built for 32-bits and uses 32-bit plugins all over the
place.
Post by David T. LewisWe collectively have a good deal of experience in updating plugins
for 64 bits, and of course the VMs (the "application") are already
there. Can you remind us what plugins are needed for Croquet that are
not already in the supported VMs?
Thanks,
Dave
Post by LawsonEnglishCroquet could STILL be the killer-app for Smalltalk even though it
never realized its potential in the past, and it won???t be able to if
something isn???t done about the looming 32-bit vs 64-bit issue.
Post by David T. LewisPost by LawsonEnglishNeed I point out that it should work on Pharo just the same way it does
on Squeak?
--
_,,,^..^,,,_
best, Eliot