<html>
<body>
Re: the Parrot register-based architecture...<br><br>
Since I'm currently interested in things Javascript I noticed a mention
of Opera working on their Javascript engine...<br>
Opera revs JavaScript engine of the future<br>
<a href="http://www.theregister.co.uk/2009/02/05/new_opera_java_script_engine/" eudora="autourl">
http://www.theregister.co.uk/2009/02/05/new_opera_java_script_engine/<br>
<br>
</a>Of course, nowadays everyone's working on faster JS engines, Mozilla,
Google, Opera, and probably even Microsoft, but these paragraphs caught
my eye:
<dl>
<dd><font size=3>Opera's core-technology team has overhauled their
JavaScript - er, ECMAScript - engine in three distinct ways. For one,
they've switched from a stack-based bytecode instruction set to a
register-based set. Rather than using a single stack of values, Carakan
stores values in fixed registers accessible by any instruction.<br>
<dd>Since there's no need to copy values to and from the top of a stack,
fewer instructions are executed and less data is copied, Bolstad
explains.</font>
</dl>And that prompted me to think about the other groups' extensive work
towards moving to native code. That necessarily means they get
registers... and indeed that is a major differentiation (at least in
their minds) between Mozilla and Google - how well they manage their
slots.<br><br>
<br><br>
Re: :dba<br><br>
People looking at the Perl 6 regular expressions in Std.pm noticed the
strange annotations embedded in the rules, e.g.<br>
:dba('yadayada') <br>
I found the explanation while reading the "Regexes and Rules"
synopsis 5,
<a href="http://perlcabal.org/syn/S05.html" eudora="autourl">
http://perlcabal.org/syn/S05.html</a> :
<dl>
<dd><font size=3>By default the error message uses the name of the
current rule as an indicator of the abstract goal of the parser at that
point. However, often this is not terribly informative, especially when
rules are named according to an internal scheme that will not make sense
to the user. The :dba("doing business as") adverb may be used
to set up a more informative name for what the following code is trying
to parse:<br><br>
</font>
<dd><pre> token postfix:sym<[ ]> {
<dd> :dba('array subscript')
<dd> '[' ~ ']'
<expression>
<dd> }
</pre>
<dd><font size=3>Then instead of getting a message like:<br><br>
</font>
<dd><pre> Unable to parse expression in
postfix:sym<[ ]>; couldn't find final ']'
</pre>
<dd><font size=3>you'll get a message like:<br><br>
</font>
<dd><pre> Unable to parse expression in array
subscript; couldn't find final ']'
</pre>
<dd><font size=3>(The :dba adverb may also be used to give names to
alternations and alternatives, which helps the lexer give better error
messages.)<br><br></font>
</dl>So once again the beauty and purity of code is polluted through
catering to users.... as if they weren't so ungrateful
anyway! ;-)<br><br>
Tom<br><br>
<x-sigsep><p></x-sigsep>
-- <br>
I'm a pessimist about probabilities; I'm an optimist about
possibilities.<br>
Lewis Mumford (1895-1990) <br>
</body>
</html>