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

[Yoshiki Ohshima]

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.

>     > - 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.

-- Yoshiki