Newsgroups: perl.perl6.internals
Path: archiver1.google.com!news2.google.com!news.maxwell.syr.edu!newsfeed.stanford.edu!nntp.perl.org
Return-Path: <d...@sidhe.org>
Mailing-List: contact perl6-internals-h...@perl.org; run by ezmlm
Delivered-To: mailing list perl6-intern...@perl.org
Delivered-To: perl6-intern...@perl.org
X-Scanned-By: AMaViS-ng at sidhe.org
Date: Fri, 17 Oct 2003 08:33:31 -0400 (EDT)
To: Robert Spier <rsp...@pobox.com>
cc: perl6-intern...@perl.org
Subject: Re: Fixed opcode numbering infrastructure in
In-Reply-To: <m3fzhswgq9.wl_rspier@pobox.com>
Message-ID: <Pine.LNX.4.58.0310170813220.10277@sprite.sidhe.org>
References: <Pine.LNX.4.58.0310161200090.777@sprite.sidhe.org> <200310162307.h9GN7hL00955@thu8.leo.home> <a05210600bbb4fea1434a@10.0.1.2> <m3fzhswgq9.wl_rspier@pobox.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Check-By: one.develooper.com
X-Spam-Status: No, hits=-1.6 required=7.0 tests=CARRIAGE_RETURNS,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01,USER_AGENT_PINE version=2.44
X-SMTPD: qpsmtpd/0.26, http://develooper.com/code/qpsmtpd/
Approved: n...@nntp.perl.org
From: d...@sidhe.org (Dan Sugalski)
Lines: 29

On Thu, 16 Oct 2003, Robert Spier wrote:

> > The goals are to assign permanent numbers to the opcodes. What the
> > numbers are is generally irrelevant, but they must be constant across
> > all systems for the lifetime of parrot.
>
> At first glance, gut reaction, that seems "really hard"(tm) and
> "really limiting"(tm)...

Luckily, on second glance, it turns out to be neither. :)

While new ops get added, old ones rarely, if ever, get removed. Perl 5's
set has been stable, as has Python's, the JVM, the x86, Alpha, SPARC, and
POWER's...

> since there's going to be a combination of dynamic oplibs that are
> going to have to be dynamically numbered anyway.  (right?)

Yes and no. Dynamic ops will go into slots, put in by name, with their
number fixed at compile-time. We'd prefer to do this as little as possible
for startup speed reasons, as it does slow down instantiating an
interpreter.

> So why not treat the core oplib as dynamic?  (With the exception of
> the handful that need to be fixed, like end.)

Speed and complexity mainly. There's no win from the flexibility.

					Dan