Much of parrot_assembly.pod seems out of date, or raises interesting
questions:

Are we going to bother with NAMESPACEs and SUBs in assembler?

(from parrot_assembly.pod:

Namespaces are noted with the NAMESPACE directive. It takes a single
parameter, the name of the namespace. Multilevel namespaces are
supported, and the namespaces should be double-colon separated.

Subroutine names are noted with the SUB directive. It takes a single
parameter, the name of the subroutine, which is added to the
namespace's symbol table. Sub names may be any valid Unicode
alphanumeric character and the underscore.

)

Is it worth keeping documentation for (implemented) opcodes in this
file, when they can be generated from pod in *.ops files as required?

Of those listed in parrot_assembly.pod, there are some which have
not yet been implemented:

jsr: marked in core.ops as "TODO: Implement this, or delete the entry."

inc: is this going to be available for PMCs ?
dec: ditto

push_*: now renamed to push*, and clone*

warp: I'd love warp opcodes, although I doubt we could write them to
      take reality as an argument, even so, we can't even warp strings
      at present.

Exceptions:  Please? (And can they be renamed: set_eh -> set_ehoh ?)

Alex Gough

Reply via email to