Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • So, unless I misread, there will be an "infinite" number of registers. That is, whatever the number of registers needed is, they will be allocated. It reminds me of the new Lua VM (which is not as standalone as Parrot is). As of version 5, this VM is changed from a stack oriented VM to a register oriented VM. It also has a lot of other similarities to Parrot. For the interested, this is an interesting document: http://www.tecgraf.puc-rio.br/~lhf/ftp/doc/sblp2005.pdf [puc-rio.br]
    • You're right, the available universe of registers is infinite in theory. But any given subroutine's register frame size will be set at compile time, so the entire frame's size can be known and JIT code can access registers of all types using fixed offsets from a single hardware register, just as now.

      BTW, that link doesn't work. At least from Austria. :-(

  • Opcode count and policy was briefly discussed. The discussion was brief because Leo and I agree that the current opcode list is excessively broad. You don’t make opcodes for all your IO and math and POSIX operations, for example. That’s what libraries are for. So many opcodes will be migrating to standard libraries.

    I don’t understand this move at all. You just said that Parrot is a virtual machine yourself. The hardware and the software it runs are both software. The only differen