Image file loading

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Image file loading

Andreas.Raab
Folks -

I think that one of the more clever hacks I did for the Android VM
deserves proper generalization in the Interpreter. Since on Android the
image is part of the (compressed) application package it's not easily
possible to pass a file handle into the VM and have the VM read the
image as an external file.

Instead, I'm preloading the image file into memory and then hacked an
implementation of the sqImageFile* and sqAlloc* functions that would
basically operate on the image in memory. I think we should formalize
this idea for two reasons:

a) It allows preloading the image into memory on platforms where the
image may not be in an external file.

b) It trivially allows mmap()ing the entire image into memory (I think
John does that on the iPhone).

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).

The VMs would generally use this along the lines of:

   memStart = self malloc(heapSize);
   fread(imageFile, memStart, fsize(imageFile));
   readImageFromHeapSize(memStart, heapSize);

and of course a backwards compatible version of
readImageFromFile:HeapSize:StartingAt: could do the same (although I'd
rather drop that function altogether since it removes the need for
supporting various sqImageFile* functions).

I'd also say that the same pattern should be used for *writing* image
files, that is we assemble the entire image in memory then call
sqImageFileWrite(fileName, heapStart, heapSize) and sqImageFileWrite is
really just a combo of fopen(); fwrite(); fclose();

I think this scheme is much nicer, less complicated and offers more
options for implementing image loading than what we currently have.

Comments?

Cheers,
   - Andreas


Reply | Threaded
Open this post in threaded view
|

Re: Image file loading

Igor Stasenko
2010/1/20 Andreas Raab <[hidden email]>:

> Folks -
>
> I think that one of the more clever hacks I did for the Android VM deserves
> proper generalization in the Interpreter. Since on Android the image is part
> of the (compressed) application package it's not easily possible to pass a
> file handle into the VM and have the VM read the image as an external file.
>
> Instead, I'm preloading the image file into memory and then hacked an
> implementation of the sqImageFile* and sqAlloc* functions that would
> basically operate on the image in memory. I think we should formalize this
> idea for two reasons:
>
> a) It allows preloading the image into memory on platforms where the image
> may not be in an external file.
>
> b) It trivially allows mmap()ing the entire image into memory (I think John
> does that on the iPhone).
>
> 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).
>
> The VMs would generally use this along the lines of:
>
>  memStart = self malloc(heapSize);
>  fread(imageFile, memStart, fsize(imageFile));
>  readImageFromHeapSize(memStart, heapSize);
>
> and of course a backwards compatible version of
> readImageFromFile:HeapSize:StartingAt: could do the same (although I'd
> rather drop that function altogether since it removes the need for
> supporting various sqImageFile* functions).
>
> I'd also say that the same pattern should be used for *writing* image files,
> that is we assemble the entire image in memory then call
> sqImageFileWrite(fileName, heapStart, heapSize) and sqImageFileWrite is
> really just a combo of fopen(); fwrite(); fclose();
>
> I think this scheme is much nicer, less complicated and offers more options
> for implementing image loading than what we currently have.
>
> Comments?
>
+100,
it allows us to avoid dependency from file position in interp.c ,
which we are talked about earlier,
since VM don't needs to read anything from file(s) anymore.
Really, let the platform code read an image into memory and tell VM
where to grab it.


> Cheers,
>  - Andreas
>
>
>



--
Best regards,
Igor Stasenko AKA sig.

Reply | Threaded
Open this post in threaded view
|

Re: Image file loading

Andreas.Raab
Oops, apologies, this was intended to go to vm-dev. Please follow-up
over there.

Cheers,
   - Andreas

Igor Stasenko wrote:

> 2010/1/20 Andreas Raab <[hidden email]>:
>> Folks -
>>
>> I think that one of the more clever hacks I did for the Android VM deserves
>> proper generalization in the Interpreter. Since on Android the image is part
>> of the (compressed) application package it's not easily possible to pass a
>> file handle into the VM and have the VM read the image as an external file.
>>
>> Instead, I'm preloading the image file into memory and then hacked an
>> implementation of the sqImageFile* and sqAlloc* functions that would
>> basically operate on the image in memory. I think we should formalize this
>> idea for two reasons:
>>
>> a) It allows preloading the image into memory on platforms where the image
>> may not be in an external file.
>>
>> b) It trivially allows mmap()ing the entire image into memory (I think John
>> does that on the iPhone).
>>
>> 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).
>>
>> The VMs would generally use this along the lines of:
>>
>>  memStart = self malloc(heapSize);
>>  fread(imageFile, memStart, fsize(imageFile));
>>  readImageFromHeapSize(memStart, heapSize);
>>
>> and of course a backwards compatible version of
>> readImageFromFile:HeapSize:StartingAt: could do the same (although I'd
>> rather drop that function altogether since it removes the need for
>> supporting various sqImageFile* functions).
>>
>> I'd also say that the same pattern should be used for *writing* image files,
>> that is we assemble the entire image in memory then call
>> sqImageFileWrite(fileName, heapStart, heapSize) and sqImageFileWrite is
>> really just a combo of fopen(); fwrite(); fclose();
>>
>> I think this scheme is much nicer, less complicated and offers more options
>> for implementing image loading than what we currently have.
>>
>> Comments?
>>
> +100,
> it allows us to avoid dependency from file position in interp.c ,
> which we are talked about earlier,
> since VM don't needs to read anything from file(s) anymore.
> Really, let the platform code read an image into memory and tell VM
> where to grab it.
>
>
>> Cheers,
>>  - Andreas
>>
>>
>>
>
>
>