<br><br><div class="gmail_quote">On Sat, Dec 4, 2010 at 1:18 AM, Eliot Miranda <span dir="ltr"><<a href="mailto:eliot.miranda@gmail.com">eliot.miranda@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br><br><br><div class="gmail_quote">On Fri, Dec 3, 2010 at 10:15 AM, Andreas Raab <span dir="ltr"><<a href="mailto:andreas.raab@gmx.de" target="_blank">andreas.raab@gmx.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div><br>
On 12/3/2010 10:07 AM, Igor Stasenko wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
On 3 December 2010 19:02, Andreas Raab<<a href="mailto:andreas.raab@gmx.de" target="_blank">andreas.raab@gmx.de</a>> wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
maybe supporting SmallInteger as methods was not a good idea :(<br>
</blockquote>
FWIW, Objects as methods weren't intended for SmallInts; they were intended<br>
for stuff like method wrappers. Using SmallIntegers for methods is a hack<br>
and I'm not surprised it doesn't work. But it is easy to fix - just wrap<br>
your ints into something else and you're good to go.<br>
</blockquote>
<br>
clearly, VM should not crash if it finds smallint in method dictionary.<br>
Of course, it may 'not work', but in less destructive way.<br>
</blockquote>
<br></div>
Well, there are limits. By the same argument you can come up with any number of things that currently crash the VM where one might say the VM should react in a less destructive way (thisContext swapSender: 0 anyone?). Performance is important in this area and having to throw in a bunch of checks all over the place is something that I'm not to fond of.<br>
</blockquote><div><br></div><div>Well, if the vm supports "objects as methods" then there needs to be a check for something fetched from a method dictionary being a CompiledMethod somewhere. It is easy to make this robust in the face of SmallIntegers. The elegance is in writing the code so that the check occurs in as few places as possible. In my current Cog I've managed to get this down to two places in the normal lookup machinery, addNewMethodToCache: for the interpreter and lookupAndCog:for: for inline cache misses. Primitives like primitiveDoNamedPrimitiveWithArgs and primitiveExecuteMethodArgsArray need to check also (5 in all in Cog) but for the normal lookup machinery things feel OK. </div>
<div><br></div></div></blockquote><div><br>Eliot, I saw these changes, but I wonder if there would be more. I said at the beginning of this thread...for example, the Interpreter has an instVar called "newMethod". If at a certain moment tht instVar has a SmallInteger, do you handle the check in all possible uses of newMethod? (ok, you did it in markAndTrace hehe)<br>
Because the methodLookUp, methodExecution, etc, are easy to think and detect. But with the markAndTrace it ONLY happened to me when trying to swap out 60000 methods and then, the probability to have a SmallInteger in newMethod was big. Otherwise, I wouldn't notice the bug hahha<br>
</div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div class="gmail_quote"><div></div><div>BTW, Mariano's use of SmallIntegers rather than wrappers is an attempt to get a very compact image and seems a reasonable experiment. Using wrappers would defeat his use-as-little-memory-as-possible purpose.</div>
<div><br></div></div></blockquote><div><br>Exactly. And since reserch is about future ;) I was thinking that tomorrow, we could have 64 bits, with more than 1 object encoded in the address: small floats, characters, points...whatever. And why not a Proxy class (subclass of ProtoObject) where you can implement your own dnu/run:with:in ? <br>
<br>I was even going to suggest change all senders of #isIntegerObject: by a new method #hasObjectHeader: oop (or whatever name)<br>and we let this prepare for when we have not only SmallInteger but other stuff.<br><br>
Cheers<br><br>Mariano<br><br><br><br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div class="gmail_quote"><div></div><div><br></div>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br>
If you really want to do something here I'd do it entirely differently: Add a primitive to the VM that can answer the question "can you execute this object?" and use it before adding something to the method dictionary. That way you won't be able to create a method dictionary that contains stuff which is not executable.<br>
<br>
Cheers,<br><font color="#888888">
- Andreas<br>
</font></blockquote></div><br><div>best</div><div>Eliot</div>
<br></blockquote></div><br>