<br><br><div class="gmail_quote">On Thu, May 7, 2009 at 11:29 AM, Yoshiki Ohshima <span dir="ltr"><<a href="mailto:yoshiki@vpri.org">yoshiki@vpri.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
At Thu, 7 May 2009 11:09:32 -0700,<br>
<div class="im">Eliot Miranda wrote:<br>
><br>
> > - remove stack access from the API, writing them as SmartSyntaxPlugins where arguments are passed in as<br>
> parameters,<br>
> > returning the result on success and 0 (not SmallInteger 0) on<br>
> > failure<br>
><br>
> In these days, nobody would care much about it, but this would<br>
> make it harder to simulate a platform independent performance primitive in the image?<br>
><br>
> I don't think it makes any difference. In the simulator the VM could e.g. use perform:withArguments: to invoke the<br>
> primitive. The real VM needs to do something similar and have glue to the platform's native calling convention, which<br>
> can be as simple as a 32-element switch statement:<br>
> switch (numArgs) {<br>
> case 0: result = primitiveFunctionPointer(stackTop()); break;<br>
> case 1: result = primtiveFunctionPointer(stackValue(1),stackTop); break;<br>
> ...<br>
> or as sophisticated as machine code generated on the fly.<br>
<br>
</div> What I mean was to debug the Slang-ish code in the Smalltalk<br>
Debugger. Putting "halt" in the primitive code in Slang and doing<br>
#doPrimitive: lets you do it, but code written in<br>
SmartSyntaxInterpreter syntax doesn't do what it says so Smalltalk<br>
debugger cannot handle it. But again, this is a minor issue now.</blockquote><div><br></div><div>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">> > - provide isImmediateObject: and use it in place of isIntegerObject: when the objective is to select heap objects.<br>
> Use<br>
> > isCharacterObject: when the objective is to select a character. I<br>
> > intend to add immediate characters within the next few months.<br>
><br>
> Are you going to use UTF-32 or UTF-16 for it?<br>
><br>
> Characters would be Unicode code points (WideString is UTF-32 right?). UTF-16 is a variable-length string encoding.<br>
> Presumably there will be primitive converters to/from UTF-16 to WideString.<br>
<br>
</div> Yes, among these choices, my vote would be for UTF-32 (for 21-bit<br>
space). But variable-length-ness doesn't really go away when even<br>
when using UTF-32, as there are composition characters.<br>
<br>
Alternatively, we could go for all UTF-8 in image representation for<br>
Strings (as a data buffer) and when you need a Character, create an<br>
instance, or return the one in a table, that is in UTF-32. And in the<br>
image side, displayable "String" should (almost) always accompany the<br>
attributes like Text.</blockquote><div><br></div><div>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.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><br>
<font color="#888888"><br>
-- Yoshiki<br>
<br>
</font></blockquote></div><br>