At 12:53 PM 8/7/2001 -0400, Sam Tregar wrote:
>On Mon, 6 Aug 2001, Dan Sugalski wrote:
>
> > No, he's right. Not dirtying cache lines is pretty much always faster than
> > dirtying them, and not twiddling with memory's faster than twiddling. And
> > unfortunately we can't really do fully platform-
At 12:41 PM 8/7/2001 -0400, Uri Guttman wrote:
> > "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
>
> DS> Not that tricky. (And no, those aren't regex variables. I'm having
> DS> LSI-11 Macro flashbacks here)
> >>
> >> wow, the macro-11 private/lexical labels! one of the very nice fe
> "ST" == Sam Tregar <[EMAIL PROTECTED]> writes:
ST> Lo tho we walk through the valley of the shadow of the JVM... Is
ST> anyone else nervous that we seem to be trying to replace GCC here?
ST> Is register allocation really something the Perl community has
ST> expertise in?
one more
On Mon, 6 Aug 2001, Dan Sugalski wrote:
> No, he's right. Not dirtying cache lines is pretty much always faster than
> dirtying them, and not twiddling with memory's faster than twiddling. And
> unfortunately we can't really do fully platform-dependent code, since it'll
> be the actual bytecode t
> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
DS> Not that tricky. (And no, those aren't regex variables. I'm having
DS> LSI-11 Macro flashbacks here)
>>
>> wow, the macro-11 private/lexical labels! one of the very nice features
>> of macro-11 that is worth stealing (if perl d
At 11:55 PM 8/6/2001 -0400, Uri Guttman wrote:
> > "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
At 11:10 AM 8/7/2001 +0200, Bart Lateur wrote:
>On Mon, 06 Aug 2001 21:55:07 -0400, Dan Sugalski wrote:
>
> >>But I do not agree that calculated jumps should be done in such a hard
> >>way.
> >
> >Nothing hard about it, really.
>
>I was referring to Hong Zhang's proposal, not yours.
Ah, OK. I ten
On Mon, 06 Aug 2001 21:55:07 -0400, Dan Sugalski wrote:
>>But I do not agree that calculated jumps should be done in such a hard
>>way.
>
>Nothing hard about it, really.
I was referring to Hong Zhang's proposal, not yours.
--
Bart.
> "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 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
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
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
---
20 matches
Mail list logo
