[squeak-dev] Mac Hyrda update

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

[squeak-dev] Mac Hyrda update

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

Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] Mac Hyrda update

Igor Stasenko
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.