[Vm-dev] mantis http://bugs.squeak.org/view.php?id=7349

[Eliot Miranda]

On Thu, May 7, 2009 at 11:29 AM, Yoshiki Ohshima <yoshiki at vpri.org> wrote:

>
> At Thu, 7 May 2009 11:09:32 -0700,
> Eliot Miranda wrote:
> >
> >     > - remove stack access from the API, writing them as
> SmartSyntaxPlugins where arguments are passed in as
> >     parameters,
> >     > returning the result on success and 0 (not SmallInteger 0) on
> >     > failure
> >
> >      In these days, nobody would care much about it, but this would
> >     make it harder to simulate a platform independent performance
> primitive in the image?
> >
> > I don't think it makes any difference. In the simulator the VM could e.g.
> use perform:withArguments: to invoke the
> > primitive. The real VM needs to do something similar and have glue to the
> platform's native calling convention, which
> > can be as simple as a 32-element switch statement:
> > switch (numArgs) {
> > case 0: result = primitiveFunctionPointer(stackTop()); break;
> > case 1: result = primtiveFunctionPointer(stackValue(1),stackTop); break;
> > ...
> > or as sophisticated as machine code generated on the fly.
>
>   What I mean was to debug the Slang-ish code in the Smalltalk
> Debugger.  Putting "halt" in the primitive code in Slang and doing
> #doPrimitive: lets you do it, but code written in
> SmartSyntaxInterpreter syntax doesn't do what it says so Smalltalk
> debugger cannot handle it.  But again, this is a minor issue now.


Ah, OK, now I get it.  I think we can fix this.  If the type information is
moved into pragmas then I think the debug issue can be made to go away.  the
simulator would have to read the pragma and type convert before it called
perform: but I think this is straight-forward.  The pragma could be e.g.
performable by the VM to do the type conversion.


> >     > - provide isImmediateObject: and use it in place of
> isIntegerObject: when the objective is to select heap objects.
> >     Use
> >     > isCharacterObject: when the objective is to select a character. I
> >     > intend to add immediate characters within the next few months.
> >
> >     Are you going to use UTF-32 or UTF-16 for it?
> >
> > Characters would be Unicode code points (WideString is UTF-32 right?).
> UTF-16 is a variable-length string encoding.
> > Presumably there will be primitive converters to/from UTF-16 to
> WideString.
>
>   Yes, among these choices, my vote would be for UTF-32 (for 21-bit
> space).  But variable-length-ness doesn't really go away when even
> when using UTF-32, as there are composition characters.
>
>  Alternatively, we could go for all UTF-8 in image representation for
> Strings (as a data buffer) and when you need a Character, create an
> instance, or return the one in a table, that is in UTF-32.  And in the
> image side, displayable "String" should (almost) always accompany the
> attributes like Text.


I'm a bit out of my depth here.  I would have thought that you would want
the basic string types to be fixed width for fast accessing, simply because
variable length doesn't scale to e.g. indexing 1 megabyte strings.  But that
for the platform interface one would want efficient conversion to/from fixed
and variable length encodings.  But that's just my gut.  I expect I'll
implement whatever y'all say makes sense.


>
> -- Yoshiki
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20090507/de18892b/attachment.htm