[Vm-dev] Re: [ANN] 7061 = Squeak 3.9 final

[David Griswold]

Hi Tim,

> -----Original Message-----
> From: vm-dev-bounces at lists.squeakfoundation.org
> [mailto:vm-dev-bounces at lists.squeakfoundation.org]On Behalf Of tim
> Rowledge
> Sent: Monday, September 25, 2006 6:58 PM
> To: Squeak Virtual Machine Development Discussion
> Subject: Re: [Vm-dev] Re: [ANN] 7061 = Squeak 3.9 final
>
> On 25-Sep-06, at 5:57 PM, David Griswold wrote:
>
> >
> > Sorry, I'm not familiar with the Squeak VM, but why does Slang
> > translate
> > into untagged C arithmetic?
> Dave, Slang _is_ the simulator effectively. It's just the Smalltalk
> code written in a pidgin sorta-C that can be executed to simulate the
> VM. Since it's just Smalltalk (albeit rather uglified Smalltalk) we
> just get to use the obvious integer overflow capabilities without
> thinking about it. Well, much. It does bop us on the nose
> occasionally when we forget that it will be turned into C.

I understand Slang is designed for generation into C, my point is that
trapping tagged
arithmetic should be easy and fast to generate in C (if they have a tag of
0), so why not generate it?   And there is a big advantage because modulo a
trap happening, which signals design failure, you get exactly the same
semantics, so debugging the VM would be easier.  Why wouldn't that be a
better way?  You wouldn't get bopped on the nose so much.

> Last case I can remember is when trying to make it possible to have
> 64 bit filepointers but still manage on OSs that don't use them.
>
> We use the bottom bit as the tag for SmallInt and leave the bottom
> two 0 for oops so there is no fiddling to extract addresses. There
> have been occasional attempts to use the second tag bit for an extra
> immediate but so far no change has been adopted. The latest VM code
> is (we think) clean for 64bit machines but a number of the vm plugins
> are not yet reworked and some platform specific code may still assume
> 32bit machines.

Yes, but using 0 for the SmallInt tag bit is much better because then the
integer
arithmetic is very fast, and having an immediate constant offset
on object dereferencing shouldn't cost anything anyway, so there
is no "fiddling".

> I have to doubt that 64bit  integers would be fast on all new
> machines. A substantial subset of 'all new machines' use ARM
> processors and they're still 32bit...... :-)

That's a good point.  But as I said, on those platforms you still would
have up to 512MB object space even with 32bits.  And won't the ARM'ers be
jealous if they find out they are missing out on 64bit tagged
double-precision
floating point ;-)

Cheers,
Dave