Here's the final draft. Please consider it formally submitted; someone
(Dan? Ask? Adam?) needs to assign it a number, please.
Dave.
=head1 TITLE
Conventions and Guidelines for Perl Source Code
=head1 VERSION
=head2 CURRENT
Maintainer: Dave Mitchell [EMAIL PROTECTED]
Class: Internals
BCW == Bryan C Warnock [EMAIL PROTECTED] writes:
BCW I was doing some thinking on the event loop (and how to tie it in
BCW later), and ran into a question. Given the current priority
BCW idea, how far does a priority stretch? (Horrible description, so
BCW let me give an example. Say
At 02:55 PM 8/6/2001 -0700, Hong Zhang wrote:
There are many typos. Please correct them.
I see. I'll fix 'em.
The branch instruction is wrong. It should be branch #num.
The offset should be part of instruction, not from register.
Nope, because that kills the potential for computed relative
The branch instruction is wrong. It should be branch #num.
The offset should be part of instruction, not from register.
Nope, because that kills the potential for computed relative
branches. (It's in there on purpose) Branches should work from
both constants and registers.
Even so, the
On Mon, 6 Aug 2001, Hong Zhang wrote:
It is not just for performance, the stack size and cache
locationality are also big issues.
Cache sizes and timings vary from machine to machine. Maybe we should
make it configurable at compile-time? If we do that then there's no
reason to try to guess
At 03:41 PM 8/6/2001 -0700, Hong Zhang wrote:
The branch instruction is wrong. It should be branch #num.
The offset should be part of instruction, not from register.
Nope, because that kills the potential for computed relative
branches. (It's in there on purpose) Branches should work
At 05:27 PM 8/6/2001 -0700, Hong Zhang wrote:
If we define caller-save and callee save. The 64 register may
not be bad, as long as caller-save set is small.
At least a full push without a copy to the new frame is dead
cheap, so it's not much of a cost.
May not be true. If we use gc,
At 07:23 PM 8/6/2001 -0400, Sam Tregar wrote:
On Mon, 6 Aug 2001, Hong Zhang wrote:
It is not just for performance, the stack size and cache
locationality are also big issues.
Cache sizes and timings vary from machine to machine. Maybe we should
make it configurable at compile-time? If we
On Mon, 6 Aug 2001 15:41:59 -0700 , Hong Zhang wrote:
Branches should work from
both constants and registers.
Even so, the branch #num should have better performance, and
it is part of any machine language. Since we already have jump
instruction, do we really need the branch %r, which can be
DS == Dan Sugalski [EMAIL PROTECTED] writes:
DS Nothing hard about it, really. We'll see either:
DSbranch $10
DS or
DSstore I12, $10
DSbranch I12
DS Not that tricky. (And no, those aren't regex variables. I'm having
DS LSI-11 Macro flashbacks here)
wow, the
At 01:47 AM 8/6/2001 -0400, Bryan C. Warnock wrote:
Okay, next set of results.
508 opcodes, arranged in a primary set of 255, and a secondary set of 253.
The primary set contained the escape opcode (opcode 0), the null opcode
(opcode 254), and the program termination opcode (opcode 255). The
At 02:17 AM 8/6/2001 -0400, Uri Guttman wrote:
a few pseudo-random thoughts, take them as pure musings.
dan has ordered^Wsuggested that the op code be a 32 bit value.
Got it right the first time. Ordered is as good a word as any. (Mandated
in the fundamental design documents is a good way
DS == Dan Sugalski [EMAIL PROTECTED] writes:
DS At 02:17 AM 8/6/2001 -0400, Uri Guttman wrote:
a few pseudo-random thoughts, take them as pure musings.
he didn't
like the escape code and 16 bits was too small a space. but i haven't
heard him spell out the op code dispatch
At 12:23 PM 8/6/2001 -0400, Uri Guttman wrote:
DS == Dan Sugalski [EMAIL PROTECTED] writes:
DS At 02:17 AM 8/6/2001 -0400, Uri Guttman wrote:
a few pseudo-random thoughts, take them as pure musings.
he didn't
like the escape code and 16 bits was too small a space. but i
DS == Dan Sugalski [EMAIL PROTECTED] writes:
but a pure 32 bit table can be very large (and sparse) if we have those
gaps you seem to propose below.
DS True, but only if we actually use the whole set. We're 32 bit for a few
DS reasons, none of which are to provide a billion opcodes:
On Monday 06 August 2001 02:17 am, Uri Guttman wrote:
dan has ordered^Wsuggested that the op code be a 32 bit value. he didn't
like the escape code and 16 bits was too small a space. but i haven't
heard him spell out the op code dispatch design for that. so, here is a
way to use a 32 bit op
At 09:35 PM 8/6/2001 -0400, Stephane Payrard wrote:
Can we expect that perl6 bytecode will be used to implement the Perl
equivalent of shared libraries.
Yes, in fact we can. :)
Perl bytecode will have three sections:
1) Fixup section. RW. This has all the real-address pointers and suchlike
Can we expect that perl6 bytecode will be used to implement the Perl
equivalent of shared libraries. I wrote an (admittedly poorly worded)
RFC to state the problem, but got no feedback: see
http://dev.perl.org/rfc/338.pod
--
stef
DS == Dan Sugalski [EMAIL PROTECTED] writes:
DS Perl bytecode will have three sections:
DS 1) Fixup section. RW. This has all the real-address pointers and
DS suchlike things stored in it. It will be abused as needed when
DS 2) Constants section. RO. Holds constants. (I bet that was a
At 09:08 AM 8/6/2001 -0400, Bryan C. Warnock wrote:
On Monday 06 August 2001 02:17 am, Uri Guttman wrote:
dan has ordered^Wsuggested that the op code be a 32 bit value. he didn't
like the escape code and 16 bits was too small a space. but i haven't
heard him spell out the op code dispatch
On Monday 06 August 2001 09:16 am, Dan Sugalski wrote:
It's probably the name causing problems. Unless things change, everything
in the executable bits of parrot's bytecode stream will be 32 bits. We
might drop that to 16 bits, but that puts a heavy burden on branches I'd
as soon not have to
21 matches
Mail list logo
