<div dir="ltr">Hi Ralph,<br><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Nov 1, 2014 at 1:37 PM, Ralph Boland <span dir="ltr">&lt;<a href="mailto:rpboland@gmail.com" target="_blank">rpboland@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"> <br><div dir="ltr">I am working on a parser generator tool (a replacement for SmaCC) and <br>one of the things I a m interested in is the direct translation of <br>language specifications into the virtual machine code (SmaCC and my <br>current version of it use Squeak as the target language).<br></div></blockquote><div><br></div><div><span style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:13px">First, a different approach than compiling to Smalltalk is to compile to a parse tree.  We do this in the pseudo JavaScript compiler we&#39;ve implemented at Cadence, translating an AST into a Squeak compiler parse tree for code generation.  Targeting a parse tree gives you much more freedom; you can express things that aren&#39;t expressible in Smalltalk.  And if you target bytecodes you can do even more.</span></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">One of the problems I have is that, for some languages, the natural translation<br>into VM code uses computed gotos.<br>There are two scenarios here:<br><br>     1) goto X  where X is a variable.<br>     2) goto  (coll at: y)  where coll is a Collection.<br></div></blockquote><div><br></div><span style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:13px">There are several ways of implementing this without computed bytecodes in the instruction set, but there is also the possibility of implementing it directly in the instruction set.</span><br style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:13px"><br style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:13px"><span style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:13px">Off the top of my head one could</span><br style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:13px"><br style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:13px"><span style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:13px">- map to perform: using some mangled selector.  Yes this is problematic because one has to split the scope between the two methods, so in general it&#39;s not a solution</span><br style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:13px"><br style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:13px"><span style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:13px">- map to a case statement, which is what Squeak does. Just map it to a sequence of compare and branches.  Or better still, to a binary tree.  Coincidentally this is used by the JIT to implement block dispatch in methods that contain more than one block.  I know of other VM implementations using it for PIC dispatch with really good performance.</span><br style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:13px"><br style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:13px"><span style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:13px">- use thisContext pc: value.  This /should/ be fine in the stack VM, but slooooow in the JIT because internally mapping bytecode pcs to machine code pcs is slow, and currently slower still because the frame will be converted to a pure context and then converted back into a frame on the return from pc:.  But this solution isn&#39;t to be rejected out-of-hand.  It can be optimized to avoid the frame conversion and the JIT might be able to optimize it.  The main problem is the compiler has no support for labels so there would be work here.</span><br style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:13px"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">For example, one such language is that of regular expressions, which I wish to translate into finite state machines implemented in VM code.<br>In this case I need case 2) gotos where coll is a collection of associations, possibly a <br>Dictionary. I also plan to write a debugger for this (and other languages) but that is another story.<br><br>I realize that the Cog VM is being built for Smalltalk (Squeak? Pharo?) for which the goto instructions are not needed and thus I assume unavailable. But there is something to<br>viewing a virtual machine as general purpose and thus the target of multiple languages as is<br>the case for the Java virtual machine.<br>If the Cog VM is viewed this way then I argue there is a need for my goto instructions<br>because some languages have need for them.<br>For example, many languages have case statements.  (I am all for object oriented<br>but I would be willing to accept a case statement in Smalltalk too;  the Squeak code <br>implemented one in Squeak doesn&#39;t cut it).<br></div></blockquote><div><br></div><span style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:13px">I&#39;ve occasionally thought about this for many years.  A computed jump might be nice.  Eg index an Array literal of pcs with the integer on top of stack, falling through on bad type or out of range.</span> <div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">Anyway, I am not arguing to Change Squeak or Smalltalk but I am arguing<br>to have my goto instructions in Cog VM. Is there any chance of this?????<br></div></blockquote><div><br></div><span style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:13px">There&#39;s no chance of me spending time implementing this any time soon.  I have too much high-priority tasks to tackle this.  But I want to encourage you or others to have a go implementing it.  It&#39;s fun!</span><br style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:13px"><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">I don&#39;t know the Squeak VM or the Cog VM either but I assume these<br>instructions don&#39;t exist because I see no need of them when the source language is<br>Squeak or any version of Smalltalk for that matter. I also assume that there is already<br>a full list of 256 instructions in the Cog VM and thus no room for my goto instructions<br>unless some instructions are removed.<br><br>Are there Cog VM instructions that are so rarely used that they could be removed without<br>unreasonably slowing down the Cog VM interpretation of byte codes generated from Squeak source code?????<br></div></blockquote><div> </div><span style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:13px">The current set has 3 unused bytecodes, one of which Spur uses, so effectively there are two unused bytecodes.</span><br style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:13px"><br style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:13px"><span style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:13px">The Cog VMs support multiple bytecode sets.  If you look at the BytecodeSets package on VMMaker you can read the class comments of the BytecodeEncoder subclasses such as EncoderForSistaV1.  These bytecode sets have a few more unused bytecodes.  This multiple bytecode set support is better implemented in Spur where there is only one compiled method header format and support for 64k literals.  So let me encourage you to move to Spur and to look at the Sista set.  The class comment of each encoder class specifies the instruction set it targets.</span><br style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:13px"><span class="im" style="font-family:arial,sans-serif;font-size:13px"><br></span><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">I accept that it will always be that almost all byte codes to be interpreted by the<br>Cog VM are generated from Smalltalk source.<br></div></blockquote><div><br></div><span style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:13px">Sure, but in Sista, the adaptive optimizer Clément Bera, Ronie Salgado and I are working on, the optimizer generates special bytecodes based in analysis of running code, /not/ from source.</span><br style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:13px"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">Good luck with the Cog VM.  I look forward to seeing it used in Squeak/Pharo.<br></div></blockquote><div><br></div><span style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:13px">Cog is already the standard VM in Squeak/Pharo.  Do you mean Spur?  Yes it&#39;s going well and should be ready by the end if the year.  Sista will be even better.  Spur is ~ 2x faster than Cog, and we hope Sista will get another 3x :-).</span><br style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:13px"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">Ralph Boland</div></blockquote><div><br></div><div>and welcome to vm-dev! </div></div><div><br></div>-- <br><div class="gmail_signature">best,<div>Eliot</div></div>
</div></div>