Am Freitag, 10. August 2007 schrieben Sie:
> To me, very fast (millions of lines a second) lexical analyzers are
> trivial to write by hand, and I really don't see the point of tools,
> and certainly not the utility of any theory in writing such code.
> If anything the formalism of a finite state m
On 10 August 2007 12:49, Robert Dewar wrote:
On 01 June 2007 11:27, Ronny Peine wrote:
>> Hi,
>>
>> my questions is, why not use the element construction algorithm?
> To me, very fast (millions of lines a second) lexical analyzers are
> trivial to write by hand,
I think you need one to lex
Ronny Peine wrote:
Hi,
my questions is, why not use the element construction algorithm? The Thomson
Algorithm creates an epsilon-NFA which needs quite a lot of memory. The
element construction creates an NFA directly and therefor has fewer states.
Well, this is only interesting in the scanner
2007/6/1, Frank Schaefer <[EMAIL PROTECTED]> wrote:
> To obtain 200-250% in speed gain won't be possible for this GCC
> optimizing compiler because of http://en.wikipedia.org/wiki/Amdahl%27s_law
Amdahl's Law talks about paralellism. That is not the case here.
He apply a different approach for le
Hi,
my questions is, why not use the element construction algorithm? The Thomson
Algorithm creates an epsilon-NFA which needs quite a lot of memory. The
element construction creates an NFA directly and therefor has fewer states.
Well, this is only interesting in the scanner creation which is no
> Like e.g. the generated code
>IF match-char1 THEN ..
>ELSIF match-char2 THEN ..
>ELSIF match-char3 THEN ..
>..
>END
> ?
Similar. It identifies ranges of character point sets and
brackets them via binary bracketting.
> Why to complicate the things? The determinist finite autom
2007/5/31, J.C. Pizarro <[EMAIL PROTECTED]> wrote:
To obtain 200-250% in speed gain won't be possible for this GCC
optimizing compiler because of http://en.wikipedia.org/wiki/Amdahl%27s_law
To understand the law's idea, to see first the red-A & blue-B graphic.
GCC throws more time optimizing th
On Thu, 31 May 2007, Andrew Haley wrote:
No. Speed is always measured in reciprocal units of time: s^-1.
A program that runs in 10 seconds has a speed of 0.1 s^-1. Thus, 200%
is (0.1 * 200/100) s^-1 faster, giving a speed of 0.3 s^-1.
Um, 0.1 * 200/100 = 0.2.
Amdahl's Law says:
speedup =
On 5/31/07, Joseph S. Myers <[EMAIL PROTECTED]> wrote:
Zack had some ideas a few years ago (I don't think they were ever posted
to a public list) about how to speed up _cpp_clean_line in particular, and
some or all of translation phases 1 to 3 in general. The idea is that you
have several Mealy
From "Frank Schaefer" <[EMAIL PROTECTED]> wrote:
Dear GCC Team,
Last weekend I finished the release of my directly coded
analyzer generator engine for Quex. First, I thought, it would
be just a nice idea to step away from table driven approach
of flex/lex. Directly coding also facilitates the st
On 31 May 2007 17:30, Andreas Schwab wrote:
> "Dave Korn" <[EMAIL PROTECTED]> writes:
>
>> On 31 May 2007 16:59, Kevin Handy wrote:
>>
>>> Diego Novillo wrote:
We are *always* interested in making GCC faster. All you need now is a
copyright assignment, the willingness to do the work (
On Thu, 31 May 2007, Andi Kleen wrote:
> "Frank Schaefer" <[EMAIL PROTECTED]> writes:
> >
> > Is there any interest in using such an engine in the GCC toolset?
>
> Right now gcc doesn't use flex so it would be probably non trivial
> to implement support. You would need to rewrite c-lex.c
All t
"Dave Korn" <[EMAIL PROTECTED]> writes:
> On 31 May 2007 16:59, Kevin Handy wrote:
>
>> Diego Novillo wrote:
>>> We are *always* interested in making GCC faster. All you need now is a
>>> copyright assignment, the willingness to do the work (or find someone to
>>> do it for you) and the time to i
On 31 May 2007 16:59, Kevin Handy wrote:
> Diego Novillo wrote:
>> We are *always* interested in making GCC faster. All you need now is a
>> copyright assignment, the willingness to do the work (or find someone to
>> do it for you) and the time to implement it.
>>
>> 200% speed gains are nice, e
Kevin Handy writes:
> Diego Novillo wrote:
> > We are *always* interested in making GCC faster. All you need now is a
> > copyright assignment, the willingness to do the work (or find someone to
> > do it for you) and the time to implement it.
> >
> > 200% speed gains are nice, especially if
Diego Novillo wrote:
We are *always* interested in making GCC faster. All you need now is a
copyright assignment, the willingness to do the work (or find someone to
do it for you) and the time to implement it.
200% speed gains are nice, especially if they can be replicated outside
the lab.
'pattern-action' pairs as
a basis for 'c-lex.c' ?
Best Regards,
Frank
Original-Nachricht
Datum: 31 May 2007 17:15:03 +0200
Von: Andi Kleen <[EMAIL PROTECTED]>
An: "Frank Schaefer" <[EMAIL PROTECTED]>
CC: gcc@gcc.gnu.org
Betreff: Re:
"Frank Schaefer" <[EMAIL PROTECTED]> writes:
>
> Is there any interest in using such an engine in the GCC toolset?
Right now gcc doesn't use flex so it would be probably non trivial
to implement support. You would need to rewrite c-lex.c
> It would be an honor for me to provide any adaptions yo
On 5/31/07 9:19 AM, Frank Schaefer wrote:
> Is there any interest in using such an engine in the GCC toolset?
We are *always* interested in making GCC faster. All you need now is a
copyright assignment, the willingness to do the work (or find someone to
do it for you) and the time to implement i
Dear GCC Team,
Last weekend I finished the release of my directly coded
analyzer generator engine for Quex. First, I thought, it would
be just a nice idea to step away from table driven approach
of flex/lex. Directly coding also facilitates the step towards
analysis of different character encodi
20 matches
Mail list logo
