[Vm-dev] VM Maker: VMMaker.oscog-eem.281.mcz

[David T. Lewis]

On Sat, Apr 06, 2013 at 05:15:43PM -0700, Eliot Miranda wrote:
>  
> On Thu, Apr 4, 2013 at 5:19 PM, David T. Lewis <lewis at mail.msen.com> wrote:
> 
> >
> > On Thu, Apr 04, 2013 at 01:25:10PM -0700, Eliot Miranda wrote:
> > >
> > > On Thu, Apr 4, 2013 at 3:17 AM, Nicolas Cellier <
> > > nicolas.cellier.aka.nice at gmail.com> wrote:
> > >
> > > >
> > > > Yes, I always wanted to ask what oops signed-ness was good for?
> > > > IMO, they could simply be declared usqInt.
> > > >
> > >
> > > +10 raisedTo: SmallInteger maxVal.  But the milk is already spilt :)
> > >
> > > I'm glad you said that.  I'm reminded of House of Cards.  "You might
> > think
> > > so but I couldn't possibly comment." ;)
> > >
> > > It might be worth-while trying to make this change and fixing the very
> > few
> > > places where signedness is important (the SmalInteger arithmetic
> > > primitives).
> > >
> >
> > IMO an object pointer should be declared sqOop to clearly distinguish
> > it from some something that is intended to be used as an integer.
> 
> 
> OK, but is sqOop a void pointer or what?  void pointers are ok except that
> they have to be cast all the time.  char * is poor; too easily confused
> with other pointers.  sqObj * (where sqObj is some opaque struct) is good.
>  Integral types are easy to deal with.  But signedness is the major thing
> to avoid.  SO either unsigned or pointer.  But which?
> 

You are missing my point. If someone is going to go to the trouble of
properly declaring object pointers, then they may as well use an intention
revealing type declaration.

In principle there is no reason that an object pointer should not refer to
the primary key in a relational database table (to pick an intentionally
rediculous example). But an object pointer is an object pointer, it is
not an integer and it is not a C pointer.

In practice, the current use of sqInt to represent object pointers is
confusing, but is not a big problem. After all, object memories of over
7 GB work fine with the 64-bit object format (limited by physical memory
on my PC as far as I can tell). Although I note with dismay that there
seems to be yet another regression here, so I'll need to hunt that down
once more :-/

Dave


> 
> > And
> > a (32- or 64-bit) location in the object memory should have its own type
> > declaration that would just coincidentally be the same size as a sqOop
> > in the current implementations. And maybe there should be one more type
> > definition to represent the 32-bit words in an indexable object.
> >
> > Dave
> >
> >
> 
> 
> -- 
> best,
> Eliot