"Leopold Toetsch" <[EMAIL PROTECTED]> wrote:
* opcode vs function / method
open P0, "data.txt", ">"
print P0, "sample data\n"
Using opcodes for all the IO has some disadvantages:
a) namespace pollution: all opcodes are reserved words in Parrot
b) opcodes aren't overridable, that is you can't provide your own 'print'
opcode for e.g. debugging
c) all such IO opcodes have to verify that the given PMC is actually a
ParrotIO PMC.
All good points; just to chalk up another opinion, I'd very much rather see
I/O stuff working as PMCs rather than as opcodes.
Combined with ...
* [ return code vs exception ]
... we can also check, if this was a void call or not (Parrot *does have*
the concept of a result context):
$I0 = pio.'print'("sample data\n") # return sucess (>=0) or failure
(<0)
pio.'print'("sample data\n") # throw exception on failure
Could perhaps get fun for compilers though - what if the program just throws
away the return value? So some optimizer that doesn't know this subtlety
sees this code and throws away the unused return value or just never emits
the assignment, and the behaviour changes. I'm not sure I like this idea.
* [ seek, tell ] and 64bit values
We want sooner or later extended Parrot register types. One of these would
be a C<Int64>) Parrot register. We currently have:
op tell(out INT, in PMC)
op tell(out INT, out INT, in PMC)
Depending on the arch (32 vs 64 bits) one of these opcodes is suboptimal.
With a new "L" (Long) register type the functionality could be handled
transparently:
$L0 = pio.'tell'()
Yes, but as you add more register types you get a combinatorial blow-up on
various opcodes. My understanding was that "I" registers were native
integers so you could get good performance, and you used a PMC if you wanted
some guarantees about what size you were talking about.
The register allocator would map 'L0' either to a pair (I0, I1) on 32 bit
arch or just to 'I0' on 64 bit arch.
Yes, but surely it becomes somewhat more than just a mapping problem? For
example, what do we do about:
add L0, L1, L2
mul L0, L1, L2
...
Jonathan
