Hi Guys -
You probably noticed that I was busy working on the latest Croquet VMs - the whole set of issues and changes that I am dealing with right now are for Croquet 1.0. It seems like things are settling down now (at least I have no obvious things on my TODO list any longer) and a consolidated version of VMMaker which includes all the issues discussed here is available at the repository at:
http://hedgehog.software.umn.edu:8888/Homebase.html
Tim - This (or perhaps the version two weeks from now ;-) is probably a good version for you to merge back into the main line when you find the time for it. There aren't many changes, just what I was dealing with in general (FloatMathPlugin, Tests, CroquetPlugin, SocketPlugin) so integration should be straightforward.
Cheers, - Andreas
On 26-Mar-06, at 10:05 PM, Andreas Raab wrote:
http://hedgehog.software.umn.edu:8888/Homebase.html
Tim - This (or perhaps the version two weeks from now ;-) is probably a good version for you to merge back into the main line when you find the time for it. There aren't many changes, just what I was dealing with in general (FloatMathPlugin, Tests, CroquetPlugin, SocketPlugin) so integration should be straightforward.
Notes from looking at the diffs - AsynchFilePlugin What about #primitiveAsyncFileWriteStart:fPosition:fromBuffer:at: count: Seems to need a fix from 'int' to 'sqInt' but you missed it. Or was that deliberate for some inscrutable reason?
B3DAcceleratorPlugin Are you wanting that added to VMMaker? IIRC it has heretofore been kept in the Balloon3D package.
CroquetPlugin Do you want that in the VMM package too? - any dependencies in image to worry about? Things in shared pools come to mind.
FilePlugin many removals of oopForPointer: ? Seems wrong to me. oopForPointer is pretty important according to Ian's writeup on 64 bit changes. Though it (the macro at least) probably does need fixing for cases were sqMemoryBase is non-0.
FloatMathPlugin - I couldn't see code beyond the class decl in your .49 package. Do you want it in VMM? And what about the tests? Not for VMMaker inclusion in my view.
Mpeg3Plugin Use of file name checking call bothers me. John, why is there a rather pointless indirection of sqFilenameFromStringOpen through ioFilenamefromStringofLengthresolveAliases ? Is the resolve alisases nonsense even needed now you've changed to OSX support only and using unix style filenames?
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: SDR: Shift Disk Right
Hi Tim -
AsynchFilePlugin What about #primitiveAsyncFileWriteStart:fPosition:fromBuffer:at: count: Seems to need a fix from 'int' to 'sqInt' but you missed it. Or was that deliberate for some inscrutable reason?
Something's wrong here... since I didn't touch that at all. It should be the same version that is on SqueakMap. Ditto for FilePlugin and oopForPointer: - I haven't touched FilePlugin at all.
B3DAcceleratorPlugin Are you wanting that added to VMMaker? IIRC it has heretofore been kept in the Balloon3D package.
Yes. Balloon3D is dead (has been for a couple of years now).
CroquetPlugin Do you want that in the VMM package too?
- any dependencies in image to worry about? Things in shared pools come
to mind.
Currently, there are no dependencies. Whether it should be kept in VMMaker ... good question. I think it might make things easier for everyone involved (any contrary opinions?).
FloatMathPlugin
- I couldn't see code beyond the class decl in your .49 package. Do you
want it in VMM? And what about the tests? Not for VMMaker inclusion in my view.
Yes, this should definitely go into VMMaker. I also think we should have those "FloatMathPluginTests" in VMMaker because they make sure that the primitives in the plugin function properly (and are therefore mostly needed for the person building the VM). I have essentially the same tests duplicated in the CroquetVMTests to ensure that (for example) the implementation of Float>>exp adheres to the requirement, but that seems independent from the VM builder's side.
Mpeg3Plugin Use of file name checking call bothers me. John, why is there a rather pointless indirection of sqFilenameFromStringOpen through ioFilenamefromStringofLengthresolveAliases ? Is the resolve alisases nonsense even needed now you've changed to OSX support only and using unix style filenames?
I'll leave this one for John.
Cheers, - Andreas
Andreas,
How does your new FloatMathPlugin work with the existing floating point? Is it meant to replace all other floating point calculations? I can see how that would be advantageous for some applications but for others the speed of hardware floating point may be more important.
OK, for now, the library you're using may be as fast as the interpreter but adding some basic floating point support to Exupery would be fairly easy.
Bryce
P.S. Andreas, I sent this directly to you by mistake. I meant to send to the list.
Bryce Kampjes wrote:
P.S. Andreas, I sent this directly to you by mistake. I meant to send to the list.
Well, then here's my reply to the list:
How does your new FloatMathPlugin work with the existing floating point? Is it meant to replace all other floating point calculations?
If you mean basic operations like add, subtract, divide, multiply by "all other calculations", then no. FloatMathPlugin includes only the following functions: acos, acosh, asin, asinh, atan, atan2, atanh, cos, cosh, exp, fmod, modf, hypot, log10, log, sin, sinh, sqrt, tan, tanh, ldexp.
I can see how that would be advantageous for some applications but for others the speed of hardware floating point may be more important.
With the exception of sqrt I have found the functions in fdlibm to be exceedingly fast (to the point of performing on par or better with the C library functions when compiled in a static C program, e.g., not counting any additional overhead for allocation etc). And sqrt is (fortunately) fairly well-defined so that (on Intel at least) we can use the hardware fsqrt instead of the fdlibm version. I'm hoping that this will be true in general (but we'll find out soon).
OK, for now, the library you're using may be as fast as the interpreter but adding some basic floating point support to Exupery would be fairly easy.
Basic floating point support would not speed up any of the above functions. Neither do the above functions do basic floating point support. These issues are fairly unrelated.
Cheers, - Andreas
On 28-Mar-06, at 11:17 AM, tim Rowledge wrote:
Mpeg3Plugin Use of file name checking call bothers me. John, why is there a rather pointless indirection of sqFilenameFromStringOpen through ioFilenamefromStringofLengthresolveAliases ? Is the resolve alisases nonsense even needed now you've changed to OSX support only and using unix style filenames?
The resolve aliases nonsense is still needed because you still can make hfs+ alias files in os-x, so then the question is at any point are you opening the alias or opening the file the alias points to?
I'll fix the pointless pointless indirection of sqFilenameFromStringOpen through ioFilenamefromStringofLengthresolveAliases
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: SDR: Shift Disk Right
-- ======================================================================== === John M. McIntosh johnmci@smalltalkconsulting.com 1-800-477-2659 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ======================================================================== ===
vm-dev@lists.squeakfoundation.org