|
|
On Sat, Apr 30, 2011 at 12:48:31AM +0200, Levente Uzonyi wrote:
>
> On Fri, 29 Apr 2011, Eliot Miranda wrote:
>
> >Have these changes been folded back into VMMaker trunk?
>
> There are no changes, this is a VM built from the Trunk.
>
> Levente
Support for Cog images (float word ordering) was added in these
two VMMaker updates, and is present in any recent VM build (but
the Windows VM has not been updated):
Name: VMMaker-dtl.189
Author: dtl
Time: 6 October 2010, 12:17:37 pm
UUID: 29192b6e-491d-4bc6-a209-5ba1c8625da0
Ancestors: VMMaker-dtl.188
VMMaker 4.3.3
Allow a standard interpreter VM to load and run an image that was saved
from a Cog or StackInterpreter VM. On image load, the storage format of
Float objects is returned to normalized word ordering (different from
platform word order for little endian platforms) and unrecognized header
flags are cleared. The image will be saved in standard interpreter format
(image format 6504 for a 32-bit image), which may subsequently be loaded
by a Cog or StackInterpreter VM.
Works for 32-bit Cog images (image format 6505) on both 32-bit and 64-bit
host (compile -m32 or -m64). Support for 64-bit image formats is not yet
implemented, see comment in #normalizeFloatOrderingInImage.
Name: VMMaker-dtl.190
Author: dtl
Time: 6 October 2010, 8:39:07 am
UUID: 4798e721-0a2b-4dea-b924-7492012a75f1
Ancestors: VMMaker-dtl.189
VMMaker 4.3.4
Fix #normalizeFloatOrderingInImage to work on 64-bit Squeak images. Float
data storage in a 64-bit image is the same as for a 32 bit image, with
the two 32-bit halves stored in the next two 32-bit words beginning at
accessibleObjectAfter: floatOop (in the case of 64-bit memory, the two
32-bit halves occupy one object memory word, while a 32-bit object memory
uses two). Therefore use the same logic in #normalizeFloatOrderingInImage
for a 64-bit image.
|
Locked
