Let me restate my proposal, because during private talk with John, we figured out that there is some misunderstanding.
Platform or 'support' code is C code written by platform maintainer. Interpreter code is generated by VMMaker , and written by us :)
What i proposing:
Interpreter provides a single API function:
Interpreter>>readImageFrom: handle,
where handle is just a (void*) pointer, which only role is to serve as an argument , which interpreter should use to identify this resource, when calling a service functions, provided by platform code.
In our specific case, the only service function, which we need is to ask platform code to read a next N bytes from given resource and store result at specified location:
Platform>>readFrom: object into: memoryLocation size: bytesToRead
here, the memoryLocation is a pointer to buffer, which Interpreter can obtain by allocating the memory or just a temporary buffer on stack.
Now, it should be more clear, what Interpreter>>readImageFrom: handle, does:
Interpreter>>readImageFrom: handle | header | self var: 'header' declareC: 'char[64]'.
"first, read first 64 bytes - an image header' (Platform readFrom: handle into: header size: 64) ~~ 64 ifTrue: [ ^ nil ].
"parse the header, and check if it is valid etc" ((self badHeaderIn: header ) ifTrue: [ ^ nil ]. "Fail sooner"
memsize := header longAt: xxx. (self isNotEnoughMemoryFor: memsize ) ifTrue: [ ^ nil ]. ....
"now, we're ready to allocate the memory for image" memory := Platform allocate: memsize + self breathingRoom.
"now read the image into allocated area" Platform readFrom: handle into: memory size: memsize.
---------------- Since allocation and reading is both controlled by platform code, one could do any tricks with it, like reserve an address space, but not commit it into physical memory, but instead lazily read only pages which is not yet in memory using a page-fault mechanism etc.
Igor Stasenko wrote:
Let me restate my proposal, because during private talk with John, we figured out that there is some misunderstanding.
Platform or 'support' code is C code written by platform maintainer. Interpreter code is generated by VMMaker , and written by us :)
What i proposing:
Makes absolutely no sense. You've now duplicated Interpreter>>readImageFromFile:heapSize:startingAt:. Without addressing *any* of the issues that started this whole discussion.
- A.
Interpreter provides a single API function:
Interpreter>>readImageFrom: handle,
where handle is just a (void*) pointer, which only role is to serve as an argument , which interpreter should use to identify this resource, when calling a service functions, provided by platform code.
In our specific case, the only service function, which we need is to ask platform code to read a next N bytes from given resource and store result at specified location:
Platform>>readFrom: object into: memoryLocation size: bytesToRead
here, the memoryLocation is a pointer to buffer, which Interpreter can obtain by allocating the memory or just a temporary buffer on stack.
Now, it should be more clear, what Interpreter>>readImageFrom: handle, does:
Interpreter>>readImageFrom: handle | header | self var: 'header' declareC: 'char[64]'.
"first, read first 64 bytes - an image header' (Platform readFrom: handle into: header size: 64) ~~ 64 ifTrue: [ ^ nil ].
"parse the header, and check if it is valid etc" ((self badHeaderIn: header ) ifTrue: [ ^ nil ]. "Fail sooner"
memsize := header longAt: xxx. (self isNotEnoughMemoryFor: memsize ) ifTrue: [ ^ nil ]. ....
"now, we're ready to allocate the memory for image" memory := Platform allocate: memsize + self breathingRoom.
"now read the image into allocated area" Platform readFrom: handle into: memory size: memsize.
Since allocation and reading is both controlled by platform code, one could do any tricks with it, like reserve an address space, but not commit it into physical memory, but instead lazily read only pages which is not yet in memory using a page-fault mechanism etc.
vm-dev@lists.squeakfoundation.org