read Spur image format

[abstraktor]

With as little modifications to our internal representations as possible/reasonable, we would like to read the Spur image format into our virtual machine.

Todo

• [x] introduce ImageVersion dispatch to SpurImageReader and read spurSpecific header
• [x] make GenericObject.decodePointers(…) respect immediate characters (when pointer & 3 == 2)
• [x] make SpurImageReader.read_body() remove bridges and usegap_length and size_of_next_segment to annotate address_offset to each chunk
• [x] make GenericObject.decodePointers(…) respect the address_offset that came from bridges and segments (when pointer & 3 == 0)
• [x] make SpurImageReader.read_object() respect the new object header format
• [x] find a way to deal with spur-objects having their class hashes instead of class pointers
• [x] run it with a real image
  • [x] do not try to resolve pointer fields whose only purpose is to align objects to 8 bytes (e.g. slots=5, but actually 6 pointer words contained, the last must be ignored)
  • [x] support characters > 0xffff (#80)
• [x] make the loaded Spur image usable
  • [x] the classformat seems to have changed: <W_PointersObject a MethodContext>.varsize() returns a negative value
  • [x] implement missing primitives 171, 175 (#identityHash for Character and Behavior) and 170 (#asCharacter for SmallInteger)

[krono]

Ain't gonna work withput modification, I think, Characters need some treatment, at least.

Tobias Pape sent from a mobile device

Am 13.05.2015 um 15:41 schrieb abstraktor notifications@github.com<mailto:notifications@github.com>:

Without modifying our internal representations, we would like to read the Spur image format into our virtual machine

— Reply to this email directly or view it on GitHubhttps://github.com/HPI-SWA-Lab/RSqueak/issues/66.

[j4yk]

Reworded the ticket accordingly.

[abstraktor]

we're working on branch: 66-read-spur

[j4yk]

Transcribed our yesterday's handwritten notes here: https://github.com/HPI-SWA-Lab/RSqueak/wiki/Image-reading

[j4yk]

Spur introduces new object format bits for 16 bit indexables and 64 bit indexables. I assume the latter ones are out of scope for now, since we have no model for 64 bit integer arrays (or do we?). How do we want to handle the 16 bit ones? One quick way would be to store the 16 bit integers as 32 bit ints in a W_WordsObject, but the point of this format might be, e.g., 16-bit bitmap pixel arrays, so that could defeat their purpose.

[timfel]

If we see any of those 16-bit indexables in the wild, we can implement it. I don't think it should be too hard, if we base it on the 16-bit display bitmap code. But I assume that you ask because you haven't encountered these, yet?

[timfel]

Another thought is that we might want to just switch to 16-bit lltype arrays for storage for these objects, rather than storing them in 32-bit arrays and masking...

[j4yk]

I just stumbled upon them not being supported while writing the test case for the formats. I have yet to let loose the Spur reading code on a complete image. The code in SpurBootstrap does not look like it would emit such indexables. If they do exist or when we will support them for completeness sake, I like the lltype idea, as long as the code does not read horribly if we do this. :-)

[timfel]

In that case, let's leave this issue open and get back to it when we need to. Unless somebody wants to do it just because... ;)

[timfel]

Closing this for now, unless we find more specific issues, this actually works now.