> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
>> so my take on that is that each module would compile to a byte stream
>> which has its own private op code table to dispatch ALL op code
>> functions called by this module. so the same op code index in two
>> different modules can
On Tuesday 07 August 2001 10:48 am, Dan Sugalski wrote:
> BTW, can I get the source to the tests? I'd like to give them a whirl to
> see how the Alphas deal with the various alternatives.
http://members.home.com/bcwarno/Perl6/spool/opcode_test.tgz
--
Bryan C. Warnock
[EMAIL PROTECTED]
At 09:40 AM 8/7/2001 -0400, Bryan C. Warnock wrote:
>On Monday 06 August 2001 09:08 am, Bryan C. Warnock wrote:
> > It could be that part of the "fixup" is to convert from bytes to wider
> > ops, or something similar. If that's the case, I can patch the code and
> > rerun it.
>
>Okay. I rewrote
On Monday 06 August 2001 09:08 am, Bryan C. Warnock wrote:
> It could be that part of the "fixup" is to convert from bytes to wider
> ops, or something similar. If that's the case, I can patch the code and
> rerun it.
Okay. I rewrote the code from scratch. (Rev 2 is always better anyway.)
Same
At 05:54 PM 8/6/2001 -0400, Uri Guttman wrote:
> > "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 whe
> "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 ex
At 05:47 PM 8/6/2001 -0400, Bryan C. Warnock wrote:
>I was doing some thinking on the event loop (and how to tie it in later),
>and ran into a question. Given the current priority idea, how far does a
>priority stretch? (Horrible description, so let me give an example. Say
>SIGALRM has been det
> "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 be
On Monday 06 August 2001 09:38 am, Dan Sugalski wrote:
> Cool. I really, *really* appreciate the work you're doing on this. It's
> definitely cemented the idea that the op dispatch loop will be generated
> dynamically, and will be different on various platforms. The wins you saw
> with different s
Actually we can use "call-setup-gp" calling convention to avoid patch.
It works like this:
1) each bytecode contains data section and code section.
2) during load, the runtime construct the data segment from the
data section, such as string object from string data, floating
point object fr
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
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
t
At 12:51 PM 8/6/2001 -0400, Uri Guttman wrote:
> > "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 fo
> "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 bi
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
> "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 o
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 wa
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). Th
At 09:31 AM 8/6/2001 -0400, Bryan C. Warnock wrote:
>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 t
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
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 disp
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 o
> "BCW" == Bryan C Warnock <[EMAIL PROTECTED]> writes:
BCW> What may also need to be considered is what the expected growth
BCW> of opcodes may actually be in future versions of Perl. In order
BCW> to maintain upwards compatability, future opcodes will need to be
BCW> added around th
On Saturday 04 August 2001 03:21 pm, Dan Sugalski wrote:
> At 01:04 PM 7/30/2001 -0400, Bryan C. Warnock wrote:
> >I'll also rework my code generator and the logic to ramp it up to four or
> >five hundred opcodes, which would be a little better test, I think.
> >Anything else I should add or tweak
At 01:04 PM 7/30/2001 -0400, Bryan C. Warnock wrote:
>I'll also rework my code generator and the logic to ramp it up to four or
>five hundred opcodes, which would be a little better test, I think.
>Anything else I should add or tweak?
See what happens if you do a mixed switch/indirect dispatch ta
On Monday 30 July 2001 09:34 am, Nick Ing-Simmons wrote:
> Bryan C . Warnock <[EMAIL PROTECTED]> writes:
> >Not that this is the most scientific testing in the world, but I did
> > write a couple variations of an opcode dispatch loop just to see how
> > they compare.
&
Not that this is the most scientific testing in the world, but I did write a
couple variations of an opcode dispatch loop just to see how they compare.
Of course, I violated rule number one of writing fast code - I didn't run it
on a slow machine. Shame on me.
Given an 80K opcode s
On Sunday 29 July 2001 12:55 am, Doofus wrote:
> Dan, et al,
> When we say that each opcode handler will return the next opcode, we
> really mean the location within the opcode stream, and not the opcode
> itself, right?
Nebbermime. RTFM. It's in PDD 5.
--
Bryan C. Warnock
[EMAIL PROTECTE
Dan, et al,
When we say that each opcode handler will return the next opcode, we
really mean the location within the opcode stream, and not the opcode
itself, right?
We are also expecting all (or most) of the opcode handlers themselves to
be pluggable, right? I'm working on some differe
29 matches
Mail list logo
