3 ms·

The magic here comes from Smalltalk's object memory system, which makes this object easy. (Well.. okay.. not completely easy, but simple.) Also... I know in Di

The magic here comes from Smalltalk's object memory system, which makes this object easy. (Well.. okay.. not completely easy, but simple.) Also... I know in Digitalk, you couldn't do a become: on SmallInteger because of the way their object memory worked, but don't remember if this was a limitation of SmallTalk-80 or Squeak. Which is to say... when you have time, if you haven't done it already, do a search on "smalltalk object memory" or "Loom" or "bluebook object memory." There are some great references from the dawn of time.

Samis2001 4y ago
The SmallInteger limitation is probably because as an optimisation they stored them as immediate values rather than generic objects, and Squeak shares this limitation (the newer Spur format extends this to one or more additional types depending on image bitness). Related to references and the above, Eliot Miranda's blog may be informative as it provides both details and sometimes code for many of the changes that have happened in the Squeak (and now OpenSmalltalk) VM, e.g. http://www.mirandabanda.org/cogblog/2013/09/13/lazy-become-and-a-partial-read-barrier/ http://www.mirandabanda.org/cogblog/2013/09/13/lazy-become-a...
thecodedmessage 4y ago
Squeak implements it with horrible performance, IIRC
- dingosity 4y ago
  I hear you. The last time I used squeak as a prototyping tool was around 2002 and yeah, the performance was pretty craptastic. I bumped into David Ungar at a conference a few years back. He mentioned there has been a fair amount of work back-ported to Squeak from some of the later Self work and maybe even from Lively Kernel for all I know. But lest someone read this thread and use it as evidence that Squeak is completely crappy, I would encourage them to do a bit of testing with a recent version. Also... I don't think people are going to use Smalltalk for it's raw performance, but in it's ability to model problems with pleasant "pure" OOP-ness.
  - Samis2001 4y ago
    There have been very extensive changes since 2002, yep, such as a much improved interpreter, a JIT, a replacement of the original object memory format which incidentally supports faster become and most recently a new bytecode set.

Samis2001 4y ago

The SmallInteger limitation is probably because as an optimisation they stored them as immediate values rather than generic objects, and Squeak shares this limitation (the newer Spur format extends this to one or more additional types depending on image bitness). Related to references and the above, Eliot Miranda's blog may be informative as it provides both details and sometimes code for many of the changes that have happened in the Squeak (and now OpenSmalltalk) VM, e.g. http://www.mirandabanda.org/cogblog/2013/09/13/lazy-become-and-a-partial-read-barrier/ http://www.mirandabanda.org/cogblog/2013/09/13/lazy-become-a...

thecodedmessage 4y ago

Squeak implements it with horrible performance, IIRC

dingosity 4y ago
I hear you. The last time I used squeak as a prototyping tool was around 2002 and yeah, the performance was pretty craptastic. I bumped into David Ungar at a conference a few years back. He mentioned there has been a fair amount of work back-ported to Squeak from some of the later Self work and maybe even from Lively Kernel for all I know. But lest someone read this thread and use it as evidence that Squeak is completely crappy, I would encourage them to do a bit of testing with a recent version. Also... I don't think people are going to use Smalltalk for it's raw performance, but in it's ability to model problems with pleasant "pure" OOP-ness.
- Samis2001 4y ago
  There have been very extensive changes since 2002, yep, such as a much improved interpreter, a JIT, a replacement of the original object memory format which incidentally supports faster become and most recently a new bytecode set.