Comments on: Klein and Squeak VM architectures http://blog.selflanguage.org/2009/07/04/klein-and-squeak-vm/ The power of simplicity Sat, 20 Feb 2010 01:16:22 +0000 http://wordpress.com/ hourly 1 By: Adam Spitz http://blog.selflanguage.org/2009/07/04/klein-and-squeak-vm/#comment-58 Adam Spitz Tue, 14 Jul 2009 21:51:25 +0000 http://blog.selflanguage.org/?p=25#comment-58 Feel free to ask questions here, or on the <a href="http://forum.selflanguage.org/" rel="nofollow">Self mailing list</a>. I've never been quite sure which of Self's ideas are already well-understood by the rest of the Smalltalk community. Maybe it'd be fun to have a series of posts here on the ways in which Self differs from Smalltalk. Feel free to ask questions here, or on the Self mailing list.

I’ve never been quite sure which of Self’s ideas are already well-understood by the rest of the Smalltalk community. Maybe it’d be fun to have a series of posts here on the ways in which Self differs from Smalltalk.

]]> By: Chris Cunnington http://blog.selflanguage.org/2009/07/04/klein-and-squeak-vm/#comment-57 Chris Cunnington Tue, 14 Jul 2009 20:29:56 +0000 http://blog.selflanguage.org/?p=25#comment-57 Hi Adam, Great to see you at the Toronto Smalltalk Users Group last night. This blog and the Self homepage are going to be very useful. I'm going to try to figure out how some of this stuff works over this summer. Chris Hi Adam,

Great to see you at the Toronto Smalltalk Users Group last night. This blog and the Self homepage are going to be very useful. I’m going to try to figure out how some of this stuff works over this summer.

Chris

]]> By: Jecel Assumpcao Jr http://blog.selflanguage.org/2009/07/04/klein-and-squeak-vm/#comment-56 Jecel Assumpcao Jr Wed, 08 Jul 2009 01:40:00 +0000 http://blog.selflanguage.org/?p=25#comment-56 Yeah, email is better for a detailed discussion. If you look at the Jazelle technology that ARM uses to speed up Java you can get a good idea of what I am talking about. http://en.wikipedia.org/wiki/Jazelle Yeah, email is better for a detailed discussion. If you look at the Jazelle technology that ARM uses to speed up Java you can get a good idea of what I am talking about.

http://en.wikipedia.org/wiki/Jazelle

]]> By: Ken Causey http://blog.selflanguage.org/2009/07/04/klein-and-squeak-vm/#comment-55 Ken Causey Tue, 07 Jul 2009 16:18:58 +0000 http://blog.selflanguage.org/?p=25#comment-55 OK, then I guess I would really like to hear some details regarding that, what can help the bytecode interpreter written in machine language. But perhaps this is not the place. OK, then I guess I would really like to hear some details regarding that, what can help the bytecode interpreter written in machine language. But perhaps this is not the place.

]]> By: Jecel Assumpcao Jr http://blog.selflanguage.org/2009/07/04/klein-and-squeak-vm/#comment-54 Jecel Assumpcao Jr Tue, 07 Jul 2009 15:35:43 +0000 http://blog.selflanguage.org/?p=25#comment-54 Ken, I eliminated B-BC (the bytecode interpreter written in bytecodes) in step 1, so the hardware in step 2 is supposed to help out C-BC (the bytecode interpreter written in machine language). These odd abbreviations don't help much - a drawing or animation would be best. Ken, I eliminated B-BC (the bytecode interpreter written in bytecodes) in step 1, so the hardware in step 2 is supposed to help out C-BC (the bytecode interpreter written in machine language).

These odd abbreviations don’t help much – a drawing or animation would be best.

]]> By: Ken Causey http://blog.selflanguage.org/2009/07/04/klein-and-squeak-vm/#comment-52 Ken Causey Mon, 06 Jul 2009 18:06:12 +0000 http://blog.selflanguage.org/?p=25#comment-52 Jecel, did you mean B-BC in 'step 2)'? I have to assume so given the mention of bytecodes. If not then I think this could use some further explanation. Jecel, did you mean B-BC in ’step 2)’? I have to assume so given the mention of bytecodes. If not then I think this could use some further explanation.

]]> By: Jecel Assumpcao Jr http://blog.selflanguage.org/2009/07/04/klein-and-squeak-vm/#comment-51 Jecel Assumpcao Jr Mon, 06 Jul 2009 02:18:36 +0000 http://blog.selflanguage.org/?p=25#comment-51 Your understanding of the Squeak-VM is correct, but some of the work I am doing on SiliconSqueak might be of interest. While the VM is actually structured as a class Interpreter which implements the bytecode engine and most of the primitives, and which inherits from ObjectMemory (unlike the "blue book" VM), I will explain it as if it were three roughly equal parts: B-BC (the bytecode interpreter in Slang (bytecodes), B-OM (the object memory in Slang) and B-PR (primitives in Slang). These get translated into C and compiled into machine code, becoming C-BC, C-OM and C-PR which run the tinyBenchmarks about 1000 times faster than the B versions. step 1) short circuit B-BC so that whenever it would have been invoked we have C-BC actually interpret the bytecodes. step 2) have special hardware speed up C-BC so that bytecodes run at roughly the same speed as machine language. step 3) now C-OM isn't really faster than B-OM nor C-PR than B-PR, so we add a detour so the Slang versions are used instead of the native code ones. The InterpreterSimulator is no longer dealing with a second and separate image, but in a Klein bottle style twist it is now controlling the image in which it is running. Many of the complications you mentioned apply to this scheme as well: how do you send messages without more sending messages, or allocate objects without allocating more objects. And while the system I described is an interpreter, adding Cog native compilation would make it even nicer. About the danger, one possible solution is to go back to having two images. A system image operates on itself (with all the advantages and risks) and it also operates on a user image running the actual application. Your understanding of the Squeak-VM is correct, but some of the work I am doing on SiliconSqueak might be of interest. While the VM is actually structured as a class Interpreter which implements the bytecode engine and most of the primitives, and which inherits from ObjectMemory (unlike the “blue book” VM), I will explain it as if it were three roughly equal parts: B-BC (the bytecode interpreter in Slang (bytecodes), B-OM (the object memory in Slang) and B-PR (primitives in Slang). These get translated into C and compiled into machine code, becoming C-BC, C-OM and C-PR which run the tinyBenchmarks about 1000 times faster than the B versions.

step 1) short circuit B-BC so that whenever it would have been invoked we have C-BC actually interpret the bytecodes.

step 2) have special hardware speed up C-BC so that bytecodes run at roughly the same speed as machine language.

step 3) now C-OM isn’t really faster than B-OM nor C-PR than B-PR, so we add a detour so the Slang versions are used instead of the native code ones. The InterpreterSimulator is no longer dealing with a second and separate image, but in a Klein bottle style twist it is now controlling the image in which it is running.

Many of the complications you mentioned apply to this scheme as well: how do you send messages without more sending messages, or allocate objects without allocating more objects. And while the system I described is an interpreter, adding Cog native compilation would make it even nicer.

About the danger, one possible solution is to go back to having two images. A system image operates on itself (with all the advantages and risks) and it also operates on a user image running the actual application.

]]>