Dan Sugalski <[EMAIL PROTECTED]> writes:
>
>I'm not entirely sure of that one--processing a full regex requires the
>perl interpreter, it's not all that modular. Though whether being able to
>yank out the RE engine and treat it as a standalone library is important
>enough to warrant being treat
At 07:40 AM 6/5/2001 -0700, Dave Storrs wrote:
>On Tue, 5 Jun 2001, Dave Mitchell wrote:
>
> > dispatch loop. I'd much rather have a 'regex start' opcode which
> > calls a separate dispath loop function, and which then interprets any
> > further ops in the bytestream as regex ops. That way we doub
On Tue, Jun 05, 2001 at 03:31:24PM -0500, David L. Nicol wrote:
> Graham Barr wrote:
>
> > I think there are a lot of benefits to the re engine not to be
> > separate from the core perl ops.
>
>
> So does it start with a split(//,$bound_thing) or does it use
> substr(...) with explicit offsets?
Graham Barr wrote:
> I think there are a lot of benefits to the re engine not to be
> separate from the core perl ops.
So does it start with a split(//,$bound_thing) or does it use
substr(...) with explicit offsets?
On Mon, Jun 04, 2001 at 06:04:10PM -0700, Larry Wall wrote:
> Well, other languages have explored that option, and I think that makes
> for an unnatural interface. If you think of regexes as part of a
> larger language, you really want them to be as incestuous as possible,
> just as any other par
> On Tue, Jun 05, 2001 at 11:25:09AM +0100, Dave Mitchell wrote:
> > This is the bit that scares me about unifying perl ops and regex ops:
> > can we really unify them without taking a performance hit?
>
> Coupl'a things: firstly, we can make Perl 6 ops as lightweight as we like.
>
> Second, Rub
On Tue, 5 Jun 2001, Dave Mitchell wrote:
> dispatch loop. I'd much rather have a 'regex start' opcode which
> calls a separate dispath loop function, and which then interprets any
> further ops in the bytestream as regex ops. That way we double the number
> of 8-bit ops, and can have all the re
Simon Cozens <[EMAIL PROTECTED]> opined:
> On Tue, Jun 05, 2001 at 11:25:09AM +0100, Dave Mitchell wrote:
> > This is the bit that scares me about unifying perl ops and regex ops:
> > can we really unify them without taking a performance hit?
>
> Coupl'a things: firstly, we can make Perl 6 ops as
On Tue, Jun 05, 2001 at 11:25:09AM +0100, Dave Mitchell wrote:
> This is the bit that scares me about unifying perl ops and regex ops:
> can we really unify them without taking a performance hit?
Coupl'a things: firstly, we can make Perl 6 ops as lightweight as we like.
Second, Ruby uses a giant
Larry Wall <[EMAIL PROTECTED]> wrote:
> It may certainly be valuable to (not) think of it that way, but just
> don't be surprised if the regex folks come along and borrow a lot of
> your opcodes to make things that look like (in C):
>
>while (s < send && isdigit(*s)) s++;
This is the bit th
> Well, other languages have explored that option, and I think that makes
> for an unnatural interface. If you think of regexes as part of a
> larger language, you really want them to be as incestuous as possible,
These days we can be that without feeling that guilty since pcre exists.
> just a
On Monday 04 June 2001 08:38 pm, Jarkko Hietaniemi wrote:
> > : Though whether being able to
> > : yank out the RE engine and treat it as a standalone library is
> > : important enough to warrant being treated as a design goal or not is a
> > : separate issue. (I think so, as it also means I can t
Jarkko Hietaniemi writes:
: > : Though whether being able to
: > : yank out the RE engine and treat it as a standalone library is important
: > : enough to warrant being treated as a design goal or not is a separate
: > : issue. (I think so, as it also means I can treat it as a black box for th
Dan Sugalski writes:
: Yeah, a lot of that's definitely a problem, as is the manipulation of the
: return stack and some assignment bits. (You can cut the time split takes in
: half by having the destination array presized, for example)
That's why the current version Perl goes to a great deal o
> : Though whether being able to
> : yank out the RE engine and treat it as a standalone library is important
> : enough to warrant being treated as a design goal or not is a separate
> : issue. (I think so, as it also means I can treat it as a black box for the
> : moment so there's less to t
Dan Sugalski writes:
: At 11:24 AM 6/4/2001 -0700, Larry Wall wrote:
: >Dan Sugalski writes:
: >: Are you speaking of the nodes in regnode.h? I hadn't considered them as
: >: regular perl opcodes--I figured they'd stay internal to the regex engine so
: >: we could keep it reasonably modular.
: >
:
At 01:09 AM 6/1/2001 -0700, [EMAIL PROTECTED] wrote:
>In my experience, perl opcodes have not been the performance bottleneck
>in perl5.
>
>It seems it isn't actually the loop that's the bottleneck in perl5. I
>profiled a whole bunch of different perl programs, using a lot of
>different versions o
At 11:46 AM 6/1/2001 -0700, [EMAIL PROTECTED] wrote:
>On Tue, May 29, 2001 at 06:20:40PM -0400, Dan Sugalski wrote:
> >
> > I really think we'll win if we have support for at least integers as well
> > as PMCs. There's potentially a lot of integer work that'll be generated by
> > the optimizer and
> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
DS> No, not really. The big reasons I wasn't planning on unification are:
DS> *) It makes the amount of mental space the core interpreter takes
DS> up smaller
not if the regex ops were developed separately. all it will do is expand
th
Jarkko Hietaniemi wrote:
> Err...a regex that isn't a regex, is this a Zen koan...? Ahhh, you
> want to emulate the state machine in Pure Perl. Okay... next thing
> you want to do is to write symbolic assembler in C...? :-)
I have my reasons :)
Actually, I want to write a c into perl compile
At 03:08 PM 6/4/2001 -0500, Jarkko Hietaniemi wrote:
>On Mon, Jun 04, 2001 at 03:43:43PM -0400, Dan Sugalski wrote:
> > At 08:34 PM 6/4/2001 +0100, Simon Cozens wrote:
> > >On Mon, Jun 04, 2001 at 02:26:26PM -0500, David L. Nicol wrote:
> > > > Does anyone have on-their-shelves a regex-into-non-re
At 04:20 PM 6/4/2001 -0400, Uri Guttman wrote:
>then regexes can be also debugged in detail with the perl debugger.
>that assumes the debugger has access to single stepping ops which is an
>intriguing idea. BTW this is the kind of feature that dan wanted the
>debugger PDD to have. having this feat
At 11:24 AM 6/4/2001 -0700, Larry Wall wrote:
>Dan Sugalski writes:
>: Are you speaking of the nodes in regnode.h? I hadn't considered them as
>: regular perl opcodes--I figured they'd stay internal to the regex engine so
>: we could keep it reasonably modular.
>
>I don't think that's a terribly s
On Mon, Jun 04, 2001 at 04:20:12PM -0400, Uri Guttman wrote:
> that doesn't address larry's point which is very important.
No, I was replying to David, so I thought I'd address his point instead.
Conventional, I know. :)
> the regex compiler needs to be able to generate the equvilent of the
> a
> "SC" == Simon Cozens <[EMAIL PROTECTED]> writes:
SC> OK, here's how you do it. Run perl -Mre=debug -e '/your regexp/',
SC> and use Perl to parse the bit in the middle. That's a state machine,
SC> so we can emulate it with subroutines.
SC> So, for instance: perl -Mre=debug -e '/fo+b
On Mon, Jun 04, 2001 at 03:43:43PM -0400, Dan Sugalski wrote:
> At 08:34 PM 6/4/2001 +0100, Simon Cozens wrote:
> >On Mon, Jun 04, 2001 at 02:26:26PM -0500, David L. Nicol wrote:
> > > Does anyone have on-their-shelves a regex-into-non-regex-perl translator?
> >
> >Does anyone have on-their-shelve
On Mon, Jun 04, 2001 at 03:43:43PM -0400, Dan Sugalski wrote:
> I think he's looking for something that turns a regex into perl that
> doesn't involve regexes.
Oh, well, if we follow Larry's suggestion and have regexp matching ops,
then we could claim that the regex *is* Perl, it's just written
At 08:34 PM 6/4/2001 +0100, Simon Cozens wrote:
>On Mon, Jun 04, 2001 at 02:26:26PM -0500, David L. Nicol wrote:
> > Does anyone have on-their-shelves a regex-into-non-regex-perl translator?
>
>Does anyone have on-their-shelves a David-Nicol-into-English translator? :)
I think he's looking for so
On Mon, Jun 04, 2001 at 02:26:26PM -0500, David L. Nicol wrote:
> Does anyone have on-their-shelves a regex-into-non-regex-perl translator?
Does anyone have on-their-shelves a David-Nicol-into-English translator? :)
> run time is not an issue
Wrong.
--
I decided to spread the bad mood: Dress
Larry Wall wrote:
> "Sure, you can download the object code for this 5 line Perl program
> into your toaster...but you'll also have to download this 5 gigabyte
> regex interpreter before it'll run."
>
> That's a scenario I'd love to avoid. And if we can manage to store
> regex opcodes and
> The fact that Perl 5's regex engine is a royal pain to deal with should
> be a warning to us.
>
> Much of the pain of dealing with the regex engine in Perl 5 has to do
> with allocation of opcodes and temporary values in a non-standard
> fashion, and dealing with the resultant non-reentrancy on
Dan Sugalski writes:
: Are you speaking of the nodes in regnode.h? I hadn't considered them as
: regular perl opcodes--I figured they'd stay internal to the regex engine so
: we could keep it reasonably modular.
I don't think that's a terribly strong argument--one could justify any
number of un
On Tue, May 29, 2001 at 06:20:40PM -0400, Dan Sugalski wrote:
>
> I really think we'll win if we have support for at least integers as well
> as PMCs. There's potentially a lot of integer work that'll be generated by
> the optimizer and, while integer opcodes might not make the interpreter
> m
On Wed, May 30, 2001 at 12:14:29PM -0400, Uri Guttman wrote:
> > "NI" == Nick Ing-Simmons <[EMAIL PROTECTED]> writes:
>
> NI> The "overhead of op dispatch" is a self-proving issue - if you
> NI> have complex ops they are expensive to dispatch.
>
> but as someone else said, we can design
> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
DS> The size of the generated bytecode's likely not going to be
DS> directly an issue in determining speed. (And we can't count on
DS> keep the locals exclusively in the register set either, as
DS> otherwise string eval won't be able
> While RISC style opcodes have a certain pleasant simplicity to them, the
> opcode overhead'll kill us. (If perl 5's anything to go by, and in this
> case I think it might be)
I don't understand what the opcode overhead you meant. It can not be worse
than stack based opcode.
> The size of the
> "LW" == Larry Wall <[EMAIL PROTECTED]> writes:
LW> We basically tried this experiment with Perl 5, and it's only a
LW> partial success. Yes, you end up with a Perl VM that can run Perl
LW> pretty fast, but it tends to complicate the mapping to other
LW> virtual machines. (Enough s
At 10:06 AM 5/30/2001 -0700, Hong Zhang wrote:
> > There's no reason why you can.t have a hybrid scheme. In fact I think
> > it's a big win over a pure register-addressing scheme. Consider...
>
>The hybrid scheme may be a win in some cases, but I am not sure if it
>worth the complexity. I persona
Uri Guttman <[EMAIL PROTECTED]> writes:
>> "NI" == Nick Ing-Simmons <[EMAIL PROTECTED]> writes:
>
> NI> The "overhead of op dispatch" is a self-proving issue - if you
> NI> have complex ops they are expensive to dispatch.
>
>but as someone else said, we can design our own ops to be as high l
At 09:35 AM 5/30/2001 -0700, Larry Wall wrote:
>Dan Sugalski writes:
>: Right, but in this case we have the advantage of tailoring the instruction
>: set to the language, and given the overhead inherent in op dispatch we also
>: have an incentive to hoist opcodes up to as high a level as we can ma
> There's no reason why you can.t have a hybrid scheme. In fact I think
> it's a big win over a pure register-addressing scheme. Consider...
The hybrid scheme may be a win in some cases, but I am not sure if it
worth the complexity. I personally prefer a strict RISC style opcodes,
mainly load, s
Dan Sugalski writes:
: Right, but in this case we have the advantage of tailoring the instruction
: set to the language, and given the overhead inherent in op dispatch we also
: have an incentive to hoist opcodes up to as high a level as we can manage.
We basically tried this experiment with Pe
Dave Mitchell <[EMAIL PROTECTED]> writes:
>
>There's no reason why you can.t have a hybrid scheme. In fact I think
>it's a big win over a pure register-addressing scheme. Consider...
Which was more or less my own position...
>
>At the start of a new scope, the stack is extended by N to create a
> "NI" == Nick Ing-Simmons <[EMAIL PROTECTED]> writes:
NI> The "overhead of op dispatch" is a self-proving issue - if you
NI> have complex ops they are expensive to dispatch.
but as someone else said, we can design our own ops to be as high level
as we want. lowering the number of op cal
> "NI" == Nick Ing-Simmons <[EMAIL PROTECTED]> writes:
NI> Uri Guttman <[EMAIL PROTECTED]> writes:
>>
>> think of this as classic CISC code generation with plenty of registers
>> and a scratch stack. this is stable technology. we could even find a
>> code generator guru (i don't kn
> >the op code is stored in network endian order and the interpreter will
> >always build a 16 bit int from the 2 bytes.
>
> Not network. Native. We can put a marker at the beginning of any bytecode
> stream, and provide an endian-swapper. That way we're always running at
> platform optimal enco
Dan Sugalski <[EMAIL PROTECTED]> writes:
>At 02:08 PM 5/30/2001 +, Nick Ing-Simmons wrote:
>>Classic CISC code generation taught "us" that CISC is a pain to code-gen.
>>(I am not a Guru but did design TMS320C80's RISC specifically to match
>>gcc of that vintage, and dabbled in a p-code for Pas
Nick Ing-Simmons <[EMAIL PROTECTED]> wrote:
> I don't like push/pop - they imply a lot of stack limit checking word-by-word
> when it is less overhead for compiler to analyse the needs of whole
basic-block
> check-for/make-space-on the stack _once_ then just address it.
There's no reason why you
At 02:08 PM 5/30/2001 +, Nick Ing-Simmons wrote:
>Uri Guttman <[EMAIL PROTECTED]> writes:
> >
> >think of this as classic CISC code generation with plenty of registers
> >and a scratch stack. this is stable technology. we could even find a
> >code generator guru (i don't know any obvious ones
Uri Guttman <[EMAIL PROTECTED]> writes:
>
>think of this as classic CISC code generation with plenty of registers
>and a scratch stack. this is stable technology. we could even find a
>code generator guru (i don't know any obvious ones in the perl6 world)
Classic CISC code generation taught "us"
Uri Guttman <[EMAIL PROTECTED]> writes:
> DS> The one handy thing about push and pop is you don't need to go
> DS> tracking the stack manually--that's taken care of by the push and
> DS> pop opcodes. They can certainly be replaced with manipulations of
> DS> a temp register and indirect regist
> "Larry" == Larry Wall <[EMAIL PROTECTED]> writes:
Larry> : Nah, bytecode'll have an endianness marker at the top. If you
Larry> : load in bytecode with the wrong endianness, the loader will
Larry> : have to swap for you.
Larry> Er. If they're not bytes, we can't call it bytecode.
Unless
> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
DS> At 04:25 PM 5/29/2001 -0400, Uri Guttman wrote:
>> here is an idea. if we use a pure stack design but you can access the
>> stack values with an index, then the index number can get large. so a
>> fixed register set would allow u
On Tue, May 29, 2001 at 04:36:51PM -0600, Nathan Torkington wrote:
> Dan Sugalski writes:
> > Okay--Parrot Object Code. (If I was feeling cleverer at the moment, I'd
> > come up with a name that has a snappier acronym. Alas I'm not... :)
>
> p-code. The p stands for Parrot :-)
No, it stands fo
> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
DS> At 02:15 PM 5/29/2001 -0700, Hong Zhang wrote:
>> > we have a simple set of load literal, push/pop (multiple) registers op
>> > codes.
>>
>> There should be no push/pop opcodes. They are simply register moves.
DS> The one ha
Dan Sugalski writes:
> Okay--Parrot Object Code. (If I was feeling cleverer at the moment, I'd
> come up with a name that has a snappier acronym. Alas I'm not... :)
p-code. The p stands for Parrot :-)
Nat
At 03:26 PM 5/29/2001 -0700, Larry Wall wrote:
>Dan Sugalski writes:
>: Nah, bytecode'll have an endianness marker at the top. If you load in
>: bytecode with the wrong endianness, the loader will have to swap for you.
>
>Er. If they're not bytes, we can't call it bytecode.
Okay--Parrot Object C
Dan Sugalski writes:
: Nah, bytecode'll have an endianness marker at the top. If you load in
: bytecode with the wrong endianness, the loader will have to swap for you.
Er. If they're not bytes, we can't call it bytecode.
Larry
At 04:25 PM 5/29/2001 -0400, Uri Guttman wrote:
> > "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
>
> DS> If someone can make a compelling argument for details on how the
> DS> registers should be done that should be visible to the bytecode
> DS> (Like, say, a variant on SPARC's windo
At 02:15 PM 5/29/2001 -0700, Hong Zhang wrote:
> > we have a simple set of load literal, push/pop (multiple) registers op
> > codes.
>
>There should be no push/pop opcodes. They are simply register moves.
The one handy thing about push and pop is you don't need to go tracking the
stack manually-
At 05:32 PM 5/29/2001 -0400, Bryan C. Warnock wrote:
>On Tuesday 29 May 2001 05:15 pm, Hong Zhang wrote:
> > > either each op code knows how many args it has,
> >
> > I like to do so, otherwise we will lose most of the performance gain.
>
>I would think, though, that some ops would benefit more fr
On Tuesday 29 May 2001 05:15 pm, Hong Zhang wrote:
> > either each op code knows how many args it has,
>
> I like to do so, otherwise we will lose most of the performance gain.
I would think, though, that some ops would benefit more from varargs.
String assembly comes to mind.
>
> > or we have
> here is an idea. if we use a pure stack design but you can access the
> stack values with an index, then the index number can get large. so a
> fixed register set would allow us to limit the index to 8 bits. so the
> byte code could look something like this:
>
> 16 bit op (plenty o
> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
DS> If someone can make a compelling argument for details on how the
DS> registers should be done that should be visible to the bytecode
DS> (Like, say, a variant on SPARC's windowing system, or forcing them
DS> on the stack such that
64 matches
Mail list logo
