[Vm-dev] Imminent change to Spur image format

[Eliot Miranda]

On Aug 11, 2014, at 9:16 AM, Clément Bera <bera.clement at gmail.com> wrote:




2014-08-11 17:37 GMT+02:00 Bert Freudenberg <bert at freudenbergs.de>:

>
> On 09.08.2014, at 00:46, Eliot Miranda <eliot.miranda at gmail.com> wrote:
>
> > Hi All,
> >
> >     as part of the Newspeak infrastructure we use at Cadence I
> implemented multiple bytecode set support and a lifting of the limits in a
> method on the number of literals and the span of branches about two years
> ago.  This work involved adding a second interpretation to the bits in a
> method header, providing 16 bits of literal count.  This was done by moving
> the primitive number out of the method header and into an optional
> callPrimitive bytecode, being the first bytecode of methods that have
> primitives.
> >
> > Now in Spur I have the opportunity to use this expanded format for the
> exsting bytecode set as well.  The SqueakV3 set does not use bytecode 139,
> which is convenient to use for its callPrimitiveBytecode.  The advantage is
> that when and if a new bytecode set is added, as is planned for the Sista
> VMs, the VM will not have to test method headers to decide which format
> they're in, because there will only be one.
>
> Just curious: how does the VM know which bytecode set to use for a given
> method?



>
> A bit is set or not in the compiled method header.


And it's the sign bit.  That means the flag bit is still available, and the
bit adjacent to it, which used to be the msb of the primitive index is
free.  More bits can be stolen from the most significant bits of the num
literals field (least 16 bits of header) cuz 64k literals is a lot ;-).
 e.g. the newspeak folks have their eyes set on those two free high bits
for an access code (a protected bit and a private bit).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20140811/64a02cd7/attachment-0001.htm