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 |
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? > 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. |
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 >> >> >> > > > |
Free forum by Nabble | Edit this page |