Ok, I've check in my changes for the Mac Carbon Hydra update, (oh
likely missing something). This also includes platform specfic pthread code and the re-worked-hacked event queue code. http://squeakvm.org/svn/squeak/branches/HydraVM I suspect the pthread code could be integrated with any effort on the unix port. To compile use the SqueakVMHydra.xcodeproj project. I also have a VMMaker-JMM.81.mcz I should put somewhere, but not sure where? I had a few notes such as the (a) ioSqueakImageSize() should return a squeakFileOffsetType (I've not fixed that yet) (b) More importantly the Hydra interpreter is NOT 32bit clean since it is missing the changes David T Lewis did for ensuring addresses > 2GB won't crash the VM. (c) I did not gunify the interp.c loop yet, someone might see about that after someone ensures the interpreter is 32bit clean. (d) You can only build the VM as a windows VM, the Hydra VMMaker changes break building macintosh, or unix VM. (e) because of (d) the carbn VM does not have the InternetConfigPlugin, MIDIPlugin, MacMenubarPlugin, SerialPlugin, and SoundGenerationPlugin (f) the GCC 3.3 compiler won't let us build a powerpc VM because "sqInt pluginStateId;" is defined for *each* plugin generated and GCC 3.3 won't link those multiple defined symbols Other fun things. Because the window VM relies on special timer magic to pop an event when the next Delay wakeup is needed, or every 20ms. We of course need to do something similar for non-windows machines. I ensure that browserPluginReturnIfNeeded() is called on each send, and on each jump backwards, similar to the original checkForInterrupts. Missing are calls on activate new method and I think perform. On the macintosh version browserPluginReturnIfNeeded puts a dummy event on the queue every 16 milliseconds for secondary VMs, or watches the clock to see if the Timer Semaphore should be queued if the current time is equal to or in the past as compared to the wakeup time. Hopefully this code handles millisecond clock rollover but I did NOT test this. Putting the event on the queue then causes the interp.c interpreter loop to exit and we then process the queue to ignore the dummy event, or fire the Timer Semaphore. Note the dummy event is needed in order for secondary VMs to unlock their mutex so that the plugin loading logic will work. Going forward I would guess some platform dependent pthread code could handle the next wakeup event, but at what cost? I'll let people fiddle with things and await feedback. |
2008/5/13 John M McIntosh <[hidden email]>:
> Ok, I've check in my changes for the Mac Carbon Hydra update, (oh > likely missing something). > This also includes platform specfic pthread code and the > re-worked-hacked event queue code. > http://squeakvm.org/svn/squeak/branches/HydraVM > I suspect the pthread code could be integrated with any effort on the > unix port. > > To compile use the SqueakVMHydra.xcodeproj project. > > I also have a VMMaker-JMM.81.mcz I should put somewhere, but not sure where? > I think SqueakSource is a good place for it. Need to register project. > > I had a few notes such as the > > (a) ioSqueakImageSize() should return a squeakFileOffsetType (I've > not fixed that yet) > (b) More importantly the Hydra interpreter is NOT 32bit clean since it > is missing the changes David T Lewis did for ensuring addresses > 2GB > won't crash the VM. > (c) I did not gunify the interp.c loop yet, someone might see about > that after someone ensures the interpreter is 32bit clean. > (d) You can only build the VM as a windows VM, the Hydra VMMaker > changes break building macintosh, or unix VM. > (e) because of (d) the carbn VM does not have the > InternetConfigPlugin, MIDIPlugin, MacMenubarPlugin, SerialPlugin, and > SoundGenerationPlugin > (f) the GCC 3.3 compiler won't let us build a powerpc VM because > "sqInt pluginStateId;" is defined for *each* plugin generated and GCC > 3.3 won't link those multiple defined symbols > > > Other fun things. > > Because the window VM relies on special timer magic to pop an event > when the next Delay wakeup is needed, or every 20ms. > > We of course need to do something similar for non-windows machines. > I ensure that browserPluginReturnIfNeeded() is called on each send, > and on each jump backwards, similar to the original > checkForInterrupts. Missing are calls on activate new method and I > think perform. > On the macintosh version browserPluginReturnIfNeeded puts a dummy > event on the queue every 16 milliseconds for secondary VMs, or watches > the clock to see if the Timer Semaphore should be queued > if the current time is equal to or in the past as compared to the > wakeup time. Hopefully this code handles millisecond clock rollover > but I did NOT test this. > Putting the event on the queue then causes the interp.c interpreter > loop to exit and we then process the queue to ignore the dummy event, > or fire the Timer Semaphore. > Note the dummy event is needed in order for secondary VMs to unlock > their mutex so that the plugin loading logic will work. > > Going forward > > I would guess some platform dependent pthread code could handle the > next wakeup event, but at what cost? > I'll let people fiddle with things and await feedback. > > -- Best regards, Igor Stasenko AKA sig. |
Free forum by Nabble | Edit this page |