Hi,
I was trying to track down a core dump in 'examples/assembly/pcre.imc'. Looking
at the code in 'library/pcre.imc' and the documentation in 'parrot_assembly.pod'
I found that 'store_globals' was misdocumented. The two parameters were
interchanged.
Looking more closely at 'parrot_assembly.pod
Bernhard Schmalhofer [EMAIL PROTECTED] wrote:
Looking more closely at 'parrot_assembly.pod' I started to find more
discrepancies between the documentation in 'ops/*.pod' and
'parrot_assembly.pod'.
This document and docs/pdds/pdd06_pasm.pod are equally outdated[1]. The one
and only current
docs/parrot_assembly.pod is just an earlier version of PDD 6.
An empowered person should remove it.
Mike
On Mon, Oct 14, 2002 at 02:31:53AM +, chromatic wrote:
I've been browsing the docs, and took the time to do a bit of copyediting.
There's room for more consistency -- sometimes the registers are called 'X'
and 'Y' and other times 'x' and 'y'.
Yes, I did notice this. Is there any sort
/attach/39768/32196/db6a98/assembly.patch
--- parrot_assembly.pod~ Sun Oct 13 19:04:11 2002
+++ parrot_assembly.pod Sun Oct 13 19:18:05 2002
-251,7 +251,7
=head2 Data manipulation
-These ops handle manipulating the data in registers
+These ops handle manipulating the data in registers
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
On Wed, 19 Dec 2001, Alex Gough wrote:
Much of parrot_assembly.pod seems out of date, or raises interesting
questions:
Are we going to bother with NAMESPACEs and SUBs in assembler?
Yup. We just haven't gotten there yet.
Is it worth keeping documentation for (implemented) opcodes
Dan --
I've made core.ops contain op documentation, and I'd like to make it
the official place where ops are documented. That means I'd like to
make sure there is nothin documented in docs/parrot_assembly.pod that
isn't equivalently or superiorly documented in core.ops and then remove
want them separate on purpose. If, at some point, someone comes along and
decides that we're a bunch of clueless fsckwits and they can do a better
job implementing Parrot, they work from parrot_assembly.pod.
Understood. OK. I'll simply make sure that where the design doc has
info we don't have
