[Vm-dev] [Fwd: Image file loading]

[Igor Stasenko]

Ohh, even better.

Platform code invoking:

sqReadImageFrom(void *object).

then, an interpreter reading a header and determining a heap size.
(a question, though, does image size encoded in header?)

once interpreter prepares a memory for image and decoding the header,
it makes a second call to platform code to read the object memory, and
we're done.

No file access, no squeakFileOffsetType mess. Nothing.
A platform code deciding these details by own!

2010/1/20 Andreas Raab <andreas.raab at gmx.de>:
>
> David T. Lewis wrote:
>>
>> On Tue, Jan 19, 2010 at 02:30:43PM -0800, Andreas Raab wrote:
>>>
>>> What I'm proposing is an additional VM entry point, called
>>>
>>>  Interpreter>>readImageFromHeap: heapStart size: heapSize
>>>
>>> which takes to arguments: The pointer to the beginning of the
>>> (pre-allocated) memory portion where the image file has been loaded or
>>> mapped and a size for the allocated memory portion. The VM then assumes
>>> that beginning at heapStart there is an image provided that it needs to
>>> properly prepare (i.e., perform byte-reversal, pointer adjustment etc).
>>
>> A suggestion:
>>
>>  Interpreter>>installImage: address size: imageSize header: header
>
> I don't like that. It implies that the support code needs to be able to
> dissect the image file to find out how much is header and how much is data.
> That implies the support code needs to know about image format, byte
> reversal, and several other things. The interpreter already does that so why
> should we have to duplicate that in the support code again?
>
>> Rationale:
>>
>> - "Install" is more appropriate that "read", since the contents of the
>>  image file have already been read.
>>
>> - "Heap" is not relevant.
>
> Fair enough. I don't really care what it's called.
>
>> - The file header is logically distinct from from the contents of the
>>  image proper, and since someone else did the reading, it seems better
>>  to pass them as two distinct things (*). The pointer to header is
>>  presumed to be a memory block of at least 64 bytes, so in the usual
>>  case of a 32 bit image read into a block of malloc'ed space, we expect
>>  that address == header + 64.
>
> See above. You're making it artificially harder for the support code by
> requiring it to dissect the file and figure out what the header is. There is
> really no point to that.
>
>> My opinion: Adding the entry point is easy to do and has a clear benefit
>> for at least one platform of interest, so we should do this. Removing
>> the existing entry point is debatable and can be done at a later time.
>
> Why do you think removing the existing entry point is debatable? I can't see
> a long-term benefit for using readImageFromFile: given that the new entry
> point trivially subsumes the old one.
>
> Cheers,
>  - Andreas
>



-- 
Best regards,
Igor Stasenko AKA sig.