Re: [pcre-dev] PCRE as FPGA

Page principale
Supprimer ce message
Auteur: Zoltán Herczeg
Date:  
À: C.J. Adams-Collier
CC: Chris Collier, pcre-dev
Sujet: Re: [pcre-dev] PCRE as FPGA
Hi,

you are not the first one who are interested in moving PCRE to an FPGA on this list. From technical point of view, you probably can put PCRE onto any device provided you can compile C code for your target platform. The core PCRE library has been written in standard C, and it depends only on basic system calls (memory allocator, memory compare/copy, etc.). Nothing special. PCRE test and grep tools requires a bit more, but you likely don't need them.

I think the difficult part will be to exploit the massively parallel nature of an FPGA. PCRE is a depth-first search engine, which uses a backtracking engine for matching. This approach provides a well predictable behaviour for users, and this level of control what makes backtracking engines so popular. JIT compiling works extremely well with PCRE, since it fits the depth-first nature of the engine, and we can do many static compiler optimizations (e.g instruction scheduling, branch optimizations). The backtracking part is very unique though. But I feel doing this on an FPGA will be really challenging, since the matching process is not designed for parallel execution. In general you need to find the first character where a depth-first search finds a match. But some restricted use cases might be good candidates (e.g find all matches).

Regards,
Zoltan

"C.J. Adams-Collier" <cjac@???> írta:
>Thanks Phillip,
>
>What I meant by "lower level" was targeting something other than an OS with
>file system, memory management and other such conveniences.
>
>Perhaps the gcc-dev list might be more appropriate, but I thought there
>might be some things more specific to the application.
>
>Have any of the list members considered putting PCRE on dedicated silicon
>and what that might entail? For example, what services does libpcre depend
>on in terms of system calls and state management which might not be
>available without a kernel between it and the hardware?
>
>Cheers,
>
>C.J.