Re: StepTalk patch: argument bytecode sign bug fix, optimization literals, stack overflow fix

[Mateu Batle]

Hi !

Stefan Urbanek wrote:

> > - Possible problem of stack overflow, returned object are never pop 
> > from stack if nobody uses them. Please check this fix.
>
> Can you send me an example code that shows this bug?

Yes, pretty simple in fact. Write a script with 50 lines like the following.
Transcript showLine: 'hello'.
Do not put too many lines, or you will get out of literals in the table.

And run with --GNU-Debug=STStack, check the index number
of the stack in push / pop operations.

> > - Optimization: literal array usage, don't create a new entry if 
> > already exists
>
> I am not sure that this is good idea. Literals are created as mutable 
> objects to maintain smalltalk compatibility. If you had two equal 
> array literals and added an objectv to one, you will have that object 
> in the other array where you thought that it was the same as before.


You are right, this optimization cannot be done. I thought the literals 
were inmutable.
Then, this makes the problem about the index to literals table even more 
important.

> > Some comments also:
> >
> > - bytecodes seem to be 1 byte long for each, operation and two 
> > arguments (max 3 bytes).
> > I think it may fall short in some cases, for example for the literals 
> > table index. This is the
> > reason of the optimization submitted in the patch, before all 
> > literals where always appended
> > to the array without checking if they could be reused.
>
> Bytecodes can be extended to any width, there is no problem with that. 
> Or ... they can be removed and replaced by direct statement tree.
>
> > - In STBytecode bytecode code and arguments are defined as short, but 
> > they are always 1 byte.
> > It does not matter that much, but it can be confusing.
>
> Better would be to ged rid of btecodes in StepTalk.


Yes, but I see this change much bigger, so I think
I will try to increase the size of bytecode when I need to.

Additionally, I submit this patch for evaluation.
It solves a bug when trying to compare classes, e.g.
(NSObject == NSObject)

Modified: 
gnustep/trunk/StepTalk/Frameworks/StepTalk/Environments/Foundation-operators.stenv
===================================================================
--- 
gnustep/trunk/StepTalk/Frameworks/StepTalk/Environments/Foundation-operators.stenv
  2004-05-26 18:37:08 UTC (rev 159)
+++ 
gnustep/trunk/StepTalk/Frameworks/StepTalk/Environments/Foundation-operators.stenv
  2004-05-26 18:39:04 UTC (rev 160)
@@ -16,10 +16,20 @@
       
        };
        
+         // added by mateu       
+        "NSObject class" = {
+            SymbolicSelectors = {
+                "="  = "isEqual:";
+                "==" = "isSame:";
+                "~=" = "notEqual:";
+                "~~" = "notSame:";
+            };
+        };
+        
        NSObject = {
            Use = ("NSObject-operators");
        };


cheers !
 Mateu