2009/4/23 Eliot Miranda eliot.miranda@gmail.com:
This perhaps has legs. But I'm already up to 6505/68003. One thing I've done in 6505/68003 is make the full screen flag word a bitmask. Bit 0 means "full screen". Bit 1 means "floats are in platform order". The rest are reserved.
nice trick :) A little OT, but i would prefer to have a full screen flag sit in the image, like:
WhatEver subclass: #Display instanceVariables: 'fullscreenFlag' ...
and then
Display>>startup self primCreateWindow: foo bar: baz fullscreen: fullscreenFlag
Floats in platform order means that internally floats are in whatever the platform's natural order is, which means least significant bits in the first word on x86, and means there are special Float at:/at:put: primtiives to answer the words in big-endian/PowerPC format no matter the underlying representation. This discussion is useful in the abstract. Making it concrete is I think premature because I'm about to start work on a new object format and GC which will definitely break backward-compatibility. But it would be good for the new format to be somewhat future-proof. One thing I'll do is ensure that the VM preserves unspecified parts of the header, so that when running an image on an older VM one doesn't lose settings. Right now our Cog VMs use parts of the header to record the size of the machine code zone, the size of the stack zone and the size of new space, none of which are recorded on older VMs. So if one saves a Cog image on the closure-enabled VMs one loses one's settings. In practice this isn't too much of a problem, but ti would be nice if it didn't happen. I'd also like to see the image read/write code respect the VM header size to allow for future expansion. I also like the ability to make the image executable on unices by leaving, say, 64 bytes, at the start of the file to fill with something like #!/bin/squeak $0 $@ VisualWorks only allowed something like 32 bytes and that's a little tight.
- Dave