> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
DS> Nothing hard about it, really. We'll see either:
DS>branch $10
DS> or
DS>store I12, $10
DS>branch I12
DS> Not that tricky. (And no, those aren't regex variables. I'm having
DS> LSI-11 Macro flashbacks here)
At 03:00 AM 8/7/2001 +0200, Bart Lateur wrote:
>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 hav
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", w
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
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
> >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, we have to clear (nullify) it,
so the gc won
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
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
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
> >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.
Eve
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 relativ
> "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
There are many typos. Please correct them.
The branch instruction is wrong. It should be "branch #num".
The offset should be part of instruction, not from register.
The register set seems too big. It reduces cache efficiency
and uses too much stack. We also have to define caller saved
register
> "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
I've put the draft of the assembly PDD up on the web.
http://www.sidhe.org/~dan/perl/perl_assembly.html or
http://www.sidhe.org/~dan/perl/perl_assembly.txt for the POD.
Not done, but good enough to start a discussion on, I think.
Dan
---
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
SIR,
I am using a utility that uses perl objects. I have installed
perl version 5.6 on my windows 2000 system having office 97.
I have to use win32 ::ole package of perl on this machine. when i run my
perl program using win32::ole, it throws me message win32::ole object
version .1403 doe
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
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
32 matches
Mail list logo
