[svn:parrot] r37222 - trunk/src/ops

Reini Urban rurban at x-ray.at
Mon Mar 9 12:03:24 UTC 2009


2009/3/9  <allison at svn.parrot.org>:
> Author: allison
> Date: Mon Mar  9 01:56:58 2009
> New Revision: 37222
> URL: https://trac.parrot.org/parrot/changeset/37222
>
> Log:
> [cage] Delete reference to ancient and long-abandoned bytecode policy,
> to avoid confusing new contributors.

So since when are we in production? My understanding is that the first
production release starts with 1.0

With this change we lost now cross-version bytecode portability
and we will win the habit of randomly changing ops and pmc numbers
as before.

The pbc designers thought about that long and hard, and set a date
when these random changes should stop and should be exchanged
about a support policy which should help keeping backwards portability.

With this change of yours we've finally lost all what the designers planned
in the beginning.

"ancient and long-abandoned" is not valid here. It was always considered
that we will start a sane pmc and ops deprecation concept with the first
"production release".
Shouldn't we postpone the first production release then to eg. 2012 and tell
the users that we are not ready yet, and that we still want to jungle
the ops and pmc indices around?

Note that all these policies only require documentation changes.

Technically, getting cross-version again might be possible by adding the pbc
and ops names additionally to the indices and if the BC version does not
match, resolve the indices via the name. That was my idea to solve this problem.


> @@ -1,6 +1,6 @@
>  # This file provides opcode name->number mapping, so we can nail down
> -# the op numbers for the core opcodes and provide
> -# backward-compatibility for bytecode.
> +# the op numbers for the core opcodes in a particular version of the
> +# bytecode and provide backward-compatibility for bytecode.
>  #
>  # The format of this file is simple:
>  #
> @@ -10,12 +10,6 @@
>  # opcode--i.e. for the "add N1, N2, N3" op the name is add_n_n_n, not
>  # add.
>  #
> -# once an opcode is added to this file it should never be
> -# removed. Opcodes that are in here but that have no corresponding
> -# function backing them (because, for example, they've been deleted,
> -# which shouldn't ever happen once we hit production) should be mapped
> -# by the ops processing programs to an exception op
> -#
>  # The numbering of opcodes whose names are *not* in this file begins
>  # immediately after the highest-numbered opcode in this file,
>  # regardless of what order it is found in. There should be *no* holes

-- 
Reini Urban
http://phpwiki.org/              http://murbreak.at/


More information about the parrot-dev mailing list