We currently have incompatible implementations of microsecond clock primitives in SqueakVM and Cog. Opinions may vary as the the preferred approach, but the inconsistencies need to be reconciled.
I have implemented the Cog primitives on SqueakVM, and the SqueakVM primitive on Cog. The platform source support for these is different on Cog and trunk, but it turned out to be straightforward to do equivalent implementations in the two VMMaker branches. I would like to suggest that we adopt a common set of three primitives in both Cog and SqueakVM trunk. We can worry about reconciling the platform sources in the future, meanwhile there is value in providing a common api for the primitives.
The three primitives of interest are these:
primitiveUtcWithOffset "Answer an array with UTC microseconds since the Posix epoch and the current seconds offset from GMT in the local time zone. This is a named (not numbered) primitive in the null module (ie the VM)"
primitiveUTCMicrosecondClock "Answer the UTC microseconds since the Smalltalk epoch. The value is derived from the Posix epoch with a constant offset corresponding to elapsed microseconds between the two epochs according to RFC 868."
primitiveLocalMicrosecondClock "Answer the local microseconds since the Smalltalk epoch. The value is derived from the Posix epoch with a constant offset corresponding to elapsed microseconds between the two epochs according to RFC 868, and with an offset duration corresponding to the current offset of local time from UTC."
I am attaching two change sets for consideration. Cog-primitiveUtcWithOffset-dtl.cs is for inclusion in oscog to provide an implementation of the SqueakVM primitiveUtcWithOffset. SqueakVM-cogMicrosecondPrimitives-dtl.cs is for inclusion in the interpreter VM to provide implementions of primitiveUTCMicrosecondClock and primitiveLocalMicrosecondClock and add them to the numbered primitives table.
Does this sound like a reasonable solution? If so, I will commit primitiveUTCMicrosecondClock and primitiveLocalMicrosecondClock to VMMaker trunk, and request that the primitiveUtcWithOffset change be added to Cog.
Thanks, Dave
Hi David,
first, thatks very much. These will enable us to simplify the time implementation significantly, and that's important.
On Wed, Aug 15, 2012 at 8:07 PM, David T. Lewis lewis@mail.msen.com wrote:
We currently have incompatible implementations of microsecond clock primitives in SqueakVM and Cog. Opinions may vary as the the preferred approach, but the inconsistencies need to be reconciled.
I have implemented the Cog primitives on SqueakVM, and the SqueakVM primitive on Cog. The platform source support for these is different on Cog and trunk, but it turned out to be straightforward to do equivalent implementations in the two VMMaker branches. I would like to suggest that we adopt a common set of three primitives in both Cog and SqueakVM trunk. We can worry about reconciling the platform sources in the future, meanwhile there is value in providing a common api for the primitives.
The three primitives of interest are these:
primitiveUtcWithOffset "Answer an array with UTC microseconds since the Posix epoch and the current seconds offset from GMT in the local time zone. This is a named (not numbered) primitive in the null module (ie the VM)"
primitiveUTCMicrosecondClock "Answer the UTC microseconds since the Smalltalk epoch. The value is derived from the Posix epoch with a constant offset corresponding to elapsed microseconds between the two epochs according to RFC 868."
primitiveLocalMicrosecondClock "Answer the local microseconds since the Smalltalk epoch. The value is derived from the Posix epoch with a constant offset corresponding to elapsed microseconds between the two epochs according to RFC 868, and with an offset duration corresponding to the current offset of local time from UTC."
I am attaching two change sets for consideration. Cog-primitiveUtcWithOffset-dtl.cs is for inclusion in oscog to provide an implementation of the SqueakVM primitiveUtcWithOffset. SqueakVM-cogMicrosecondPrimitives-dtl.cs is for inclusion in the interpreter VM to provide implementions of primitiveUTCMicrosecondClock and primitiveLocalMicrosecondClock and add them to the numbered primitives table.
Does this sound like a reasonable solution? If so, I will commit primitiveUTCMicrosecondClock and primitiveLocalMicrosecondClock to VMMaker trunk, and request that the primitiveUtcWithOffset change be added to Cog.
It does, but I need some time to integrate first. I'll report back soon.
Thanks, Dave
vm-dev@lists.squeakfoundation.org