Hello, Both classes (SmallFloat64 and BoxedFloat64) are present on 32 bits and 64 bits by default right now. The code base is common between 32 and 64 bit images. It is possible to run a 32 bit image without the class SmallFloat64, but it is not the default behavior. There are no instances of SmallFloat64 in 32 bits and there can't be any. There are details, such as the SmallFloat64 class needs to be present to convert a 32 bit image to 64 bits with the offline converter and if the code base remains common between 32 and 64 bit images, then the specialObjectsArray will hold a reference to SmallFloat64 which needs to be updated if one removes the SmallFloat64 class.
For servers and desktop application it does not really make sense any more to remove these classes in 32 bits as they represent very few kb compared to Gb of RAM for laptops and Tb for servers. The Smalltalk image is already much smaller than let's say, the JVM default runtime. In addition, most computers are 64 bits now so it usually does not make sense to release in 32 bits. On embedded devices, one can consider deploying without classes such as SmallFloat64 or LargeInteger to minimize the memory footprint. The support for such feature is not very good currently, but it is getting slowly better. It could make sense to remove such classes if you are targeting a connected object with let's say an ARM Cortex-M4. This is part of a larger problem which consists in making the Pharo Kernel modular so that we can load only part of it in specific contexts to save memory or to reduce the system capabilities. 2016-02-02 14:43 GMT+01:00 Werner Kassens <wkass...@libello.com>: > On 02/02/2016 02:30 PM, Sven Van Caekenberghe wrote: > >> Maybe those classes could exist in a 32-bit image as empty subclasses of >> float ? >> > that is, what i hope <g> > > werner > >
