Re: How do tagged data structures work in Strongtalk?

On May 27, 12:54 am, Richard <[email protected]> wrote:
> I'm wondering how tagged data structures work in strongtalk. Are
> objects always 4 byte aligned allowing the low two order bytes to be
> used for tagging.

yes, all oops are 4-byte aligned.

> If this is the case how to floats and doubles work?
> How do you gracefully move from an unboxed double to a boxed double?
> Or are doubles always boxed? What about floats?

The only unboxed values in strongtalk are smis (smallintegers). All
others are full heap-allocated objects. There are no single precision
floating point values in strongtalk, only 64-bit fp (C "double").
doubleOops take 128 bit: 4 byte GC header, 4 byte class oop, 8 byte
data.

> Is there a primitive array type that allows one to have an array of
> doubles?

At the VM level, yes. But it's not implemented in the system. All
arrays working on raw data (even external data) will probably be
unified.

> Is there a way to have such an array interact gracefully with
> an Object array? e.g. if you put an object in your double array can it
> turn into an Object array with boxed doubles?

Of course. If you have basic encapsulation, #at: will always return
objects, to access doubles the VM will box them.

> Is this type of
> situation helped by having a static type system in strongtalk?

No. The static type system is irrevelant to the implementation and
performance of the VM.

>
> I presume the recent brenchmarking example discussed in relation to
> memory allocation was designed to test the precision of strongtalk
> arithmetic as well as its performance.

What benchmark do you have in mind exactly ?

>
> Is there accepted wisdom of the merits of boxed and unboxed primitive
> types in smalltalk/strongtalk?

First, there's only one type in smalltalk/strongtalk: objects.
Regarding implementation, smis have indeed different semantics from
most objects: they are not heap-allocated (you can't only pass them by
copy, never by reference). This is common in smalltalks. Everything
else is boxed objects.

>
> Has anyone looked at LLVM?

I did.

> How relevent is LLVM to the strongtalk
> project?

LLVM isn't revelant to strongtalk. It's too big, too heavy, too
generic. Strongtalk isn't a research project.

>
> regards,
>
> Richard.

I hope this answers your questions.

regards,
prunedtree


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Strongtalk-general" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [email protected]
For more options, visit this group at http://groups.google.com/group/strongtalk-general?hl=en
-~----------~----~----~----~------~----~------~--~---