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 that scares
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
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, 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
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
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 part
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 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?
Eh ?
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 double the
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
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 an
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 state
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
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
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+bar/'
SC
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 strong
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 feature
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-regex-perl
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 compiler
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
the op table,
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, while
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 of
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.
:
: I
: 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 try
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 the
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 treat it
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 as
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 our own ops to be
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
much
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 you want to
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 register stores
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 that
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 in the
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 Pascal way
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 know any obvious ones
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 calls is the
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 new
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
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,
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 level
as we want.
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 personally
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 to find
I've been out of touch this weekend (and currently sorta swamped now) so
I've not been commenting, but here's a quick sum-up of what I've been
thinking about:
1) The paired register thing's silly. Forget I mentioned it.
2) The interpreter will have some int, float, and string registers. Some
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 pushes and
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 of
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 from
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 windowing system, or
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
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
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 handy thing about push
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 for
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 us to limit the
52 matches
Mail list logo
