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

Bert Freudenberg bert at freudenbergs.de
Mon Apr 8 05:38:52 UTC 2013


Pointer to struct seems like the most obvious choice. 

- Bert -


On 06.04.2013, at 17:15, Eliot Miranda <eliot.miranda at gmail.com> 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?
>  
>> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20130407/7e69417b/attachment.htm


More information about the Vm-dev mailing list