Here's the VM event template:
typedef struct sqInputEvent
sqIntptr_t type; /* type of event; either one of EventTypeXXX */
usqIntptr_t timeStamp; /* time stamp */
/* the interpretation of the following fields depend on the type of the event */
sqIntptr_t windowIndex; /* SmallInteger used in image to identify a host window structure */
The interesting thing here is that the timeStamp is already a 64-bit quantity on 64-bit platforms. So it is trivial to use UTC microseconds divided by 1000, or (UTC microseconds minus start microseconds) divided by 1000, to timestamp events on 64-bit platforms.
On 32-bit platforms we could either add an extra field at the end, or do something heinous with type. We could use 8 bits for the type and the top 24 bits to extend the 32-bit timestamp to 56 bits, which gives us 2.28 million years of milliseconds, or 2.28 thousand years of microseconds, while still leaving us 248 new event types (we use 8 at the moment).
So why don't we
- modify the VM to stamp events with the utc second clock, either using the full 64-bits of the timestamp on 64-bit platforms, or the 32-bit timestamp and the top 24 bits of the type field on 32-bit platforms.
- add a flag to the image flags that says whether events are time stamped in utc microseconds (if set) or in wrapping milliseconds from startup (or whatever the cross-platform backward-compatiblity semantics should be)
- modify primitive 94 primitiveGetNextEvent to examine the flag and either pass the event up as is, or convert it into a backards=compatible event depending on the flag copied from the image header at startup?
The benefit is that we can ditch support for millisecond time stamps in all parts of the VM other than in primitive 94 primitiveGetNextEvent.
On Tue, Sep 15, 2020 at 9:04 AM Eliot Miranda <[hidden email]> wrote:
|Free forum by Nabble||Edit this page|