Extending the Squeak Virtual Machine
Extending the Squeak Virtual Machine, by Andrew Greenberg
Latest draft: greenberg.pdf
Promised Reviewers:
Jörn Eyrich (Joern.Eyrich@brokat.com)
Comments:
From Tim Rowlege:
A quick look suggests an excellent start - particularly since you explain a few things I can now refer to instead of having to explain myself :-)
I didn't notice any explanations of quite a lot of the TestInterpreterPlugin stuff, which I hope will make it to a later draft. It's too important to leave out.
I also need to get an explanation to you of the changes made for the pluginizedVM - a couple of extra things like setInterpreter: were needed.
Very well done job, Andrew!
This is a model of how to write such a thing.
Henrik
Some typos:
p.3: (picky, sorry!)
By far, the more flexible
and adaptable solution -and the primary subject of this chapter - are named,
or ?pluggable? primitives.
should be:
"is named"... or "is to use named"...
p.3:
(in the MacOS, for example, by dragging plugin files
into certain folders),
might be changed to for example:
... into the VM's folder
p.7:
0 to: numInstVars do: [self foo: (p at: I)]
should probably be
0 to: numInstVars do: [:i | self foo: (p at: i)]
p.8:
As side effects, #fetchInteger:ofObject: will fail unless the oop
corresponds to a SmallInteger, and #fetchInteger:ofObject will fail if
the oop corresponds to a SmallInteger.
should probably be:
... and #fetchPointer:ofObject will fail ...
.. next review ..
Have not had the time read all yet. So far excellent. Well formulated and informative.
More comments later (I hope).
Mats Nygren
Mark's Review of "Extending the Squeak Virtual Machine"
As a sign of the value of this chapter, several of my students have already downloaded it and are using it in their projects. In fact, an undergrad recently asked a question on our internal "Squeakers" list which was answered with "Greenberg, p. 16." Clearly, this is an important chapter with very important content.
My concerns with the chapter are mostly in terms of structure and order of events. "Slang" doesn't get introduced until pretty late in the chapter (p. 13), and the basic idea of producing primitives through Squeak doesn't get will articulated (e.g., sending the plugin "translate") until then, yet every single example of code is matched Squeak and C equivalents. I love the idea of the equivalents, but when I first came to them I wondered, "Why am I seeing this? I thought that primitives were written in C – why do I need this Squeak code?"
My suggestion is to start the chapter just as you do – it's a nice discussion of why you might want a primitive. And then, BEFORE the anatomy of an extension, explain the process of primitives: Producing them in C and linking them in, or producing them in Slang. Then go ahead and describe the anatomy, the Smalltalk objects "shapes" issues, and so on as you do.
Issues:
- p. 3: Typographically, identifying the keywords with "quotes" doesn't work that well. They're blending in and I'm not catching the introduction of important terms. Perhaps italicizing things like "oop" and using the System character style (defined in the template) for things like setInterpreter?
- p. 4: The description of the four "shapes" of Squeak objects could use some explanation from a Squeak perspective. While I think I generally figured out what you meant, a one-liner or so saying "Other non-indexable Smalltalk objects includes objects made like this..."
- Throughout (e.g., p. 7), you refer to methods as #firstField:. While it works, the standard in the rest of the book is to use the Symbol character style in Word and drop the prefix "#".
- p. 18. I'm guessing that more is going to appear in "The Mechanics of Building a Plugin"? The jump into "The Need for Speed" section was confusing, and I couldn't figure out why we were talking about relatively strange operations on strings until p. 20 when I realized that you were providing an example.
- p. 20: There's a "_" there that should either be the backarrow (from the Symbol font) or a :=.
- p. 12 "in a manner..." Who are you quoting here?
from Jörn Eyrich:
I used Acrobat's annotation features, which might not have been as clever an idea as I would have thought. Here is a 69K zip of the annotated pdf greenberg_annot.zip
Question
from Andy
Thanks to everyone for their attentive, and often kind, remarks.
The primary issue, it seems is the cursory treatment and substantial use of the term Slang. I had originally thought that Tim's paper was going to introduce the topic, and intended to refer by citation, but that doesn't seem to be how things are happening. I would be pleased to introduce a chapter on Slang, but it will likely increase substantially the length of the paper, which is already over-budget.
Secondly, there seems to be repeated inquiries for detailing the new "testPlugin" primitive structure. Again, I'd be pleased to do so, but I would be pressing my budget for parchment real estate.
Woudl it be OK to do the slang or testPlugin segments, even if it made the paper overlong?
From Jörn: I would love to see something about slang, maybe it should even have its own chapter
TestPlugin would be nice, too, of course, but if you must choose between the two for space rasons, my vote is for slang
From Tim - sorry if I ended up not explaining Slang! I'm having to cut back quite a bit of stuff due to bad time management on my part. If you can manage to explain anything at all about writing in Slang within your time available, go for it - please!
I would like to know how does the squeak virtual machine interact with other compiler or maybe different processor(dynamic compilation) such as the FPGA
Link to this Page