At 08:01 AM 7/31/2001 -0400, Andrew Kuchling wrote:
>On Mon, Jul 30, 2001 at 08:08:47PM -0700, Nathan Torkington wrote:
> >Andrew Kuchling writes:
> >The core loop would just be the usual opcode dispatch loop ("call the
> >function for the current operation, which returns the next
> >operation"). The only difference is that some of the opcodes would be
> >specific to RE matches. (I'm unclear on how much special logic RE
>
>The big difference I see between regex opcodes and language opcodes is
>that regexes need to backtrack and language ones don't.
Backtracking in regexes isn't all that much different from some of the
things you do at the language level, and certainly it's a straightforward
mapping of regexes onto a series of string & integer register manipulations
with simple branch-and-test code, with perhaps some stack space thrown in
for deeply nested regexes.
>Unless the
>idea is to compile a regex to actual VM code similar to that generated
>by Python/Perl code, but then wouldn't that sacrifice efficiency?
The idea is (currently, barring bad performance) to compile down to VM code
similar to what Ptyhon or perl would generate. There's the potential to
slow things down, which I'm rather nervous about. On the other hand, the
sort of code that would get emitted for regexes maps very well onto the
instruction sets of hardware CPUs, so you'd get a corresponding boost in
speed once translated to machine code. (Though granted you'd need to be
able to do the conversion on the fly, as the regex itself isn't guaranteed
to be known at compile time)
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
dan@sidhe.org have teddy bears and even
teddy bears get drunk
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4