LRSTAR is a fast LALR(k) parser generator for C/C++ programmers, that
builds very fast compilers and language processors by using
compressed-matrix parser tables. Creates compiler front-ends that
read source code at 1,000,000 lines per second.
LRSTAR reads the powerful TBNF grammar notation which facilitates
building an AST automatically and other advanced functionality.
Solves the "typedef" problem in C grammars.
The compiler front-end source code is in C++, however, a user may re-
write the skeleton file in another language, such as C, C#, Java, and
then generate code in that language. Contains Microsoft Visual Studio
C/C++ work spaces.
DFASTAR and DFAC lexer generators are included in the downloads.
These generate very fast DFA lexical analyzers which read 30,000,000
tokens per second -- twice the speed of Flex.
LRSTAR is "open source" now, BSD license. A windows version is
available at:
No one has ported it to Unix or Linux yet. It may be 99% portable.
It was written with Microsoft Visual
Studio 2008 C++, however, I try to make my code portable.
To accomplish LALR(k) it uses nondeterminism only for those states
that are not LALR(1), so it's mostly LALR(1) and the parsers are small
and fast.
On Tue, 07 Feb 2012 14:47:17 -0800, Paul B Mann wrote:
> No one has ported it to Unix or Linux yet. It may be 99% portable.
> It was written with Microsoft Visual
> Studio 2008 C++, however, I try to make my code portable.
UNIX and unix-like system are case sensitive. There is no chance that
this code will build without a significant porting effort. For
example, you have Global.H in some directory; yet, your source has
'#include "global.h"'.
It may also be advantageous to include simple instructions of which
files need to be compiled and the order.
> On Tue, 07 Feb 2012 14:47:17 -0800, Paul B Mann wrote:
>> No one has ported it to Unix or Linux yet. It may be 99% portable.
>> It was written with Microsoft Visual
>> Studio 2008 C++, however, I try to make my code portable.
> UNIX and unix-like system are case sensitive.
Except OS X, which is certified UNIX in versions 10.6 and later. (Though
one can choose a case sensitive file system, some software, notably from
Adobe, will not run properly.)
> There is no chance that
> this code will build without a significant porting effort. For
> example, you have Global.H in some directory; yet, your source has
> '#include "global.h"'.
As long the file is not called differently, this is not so a big problem
- just change the file name.
> UNIX and unix-like system are case sensitive. There is no chance that
> this code will build without a significant porting effort. For
> example, you have Global.H in some directory; yet, your source has
> '#include "global.h"'.
> It may also be advantageous to include simple instructions of which
> files need to be compiled and the order.
I can rename those header files and do a global change on the
include filenames in Visual Studio in about 15 minutes.
Is it really that difficult to do this with UNIX ?
I will make sure the next release has these changes.
Thanks for the valuable feedback. I really appreciate it.
Paul B Mann
[It's easy enough if you know what the files are and where all the
include statements are. -John]
> UNIX and unix-like system are case sensitive. There is no chance that
> this code will build without a significant porting effort. For
> example, you have Global.H in some directory; yet, your source has
> '#include "global.h"'.
> It may also be advantageous to include simple instructions of which
> files need to be compiled and the order.
I have created a newer release: 3.0.211 in which I renamed the file
names to all lower case and changed the #include filenames to match.
I also added "readme.txt" files to the "source" directories which
tells you how to compile under UNIX/Linux (i.e. compile the
"lrstar.cpp" file, the "dfastar.cpp" file and the "dfac.cpp" file).
I'm sure there will be more changes needed, because I'm not so
familiar with UNIX.
On Fri, 10 Feb 2012 13:24:41 -0800, Paul B Mann wrote:
>> UNIX and unix-like system are case sensitive. There is no chance that
>> this code will build without a significant porting effort. For
>> example, you have Global.H in some directory; yet, your source has
>> '#include "global.h"'.
>> It may also be advantageous to include simple instructions of which
>> files need to be compiled and the order.
> I have created a newer release: 3.0.211 in which I renamed the file
> names to all lower case and changed the #include filenames to match.
> I also added "readme.txt" files to the "source" directories which
> tells you how to compile under UNIX/Linux (i.e. compile the
> "lrstar.cpp" file, the "dfastar.cpp" file and the "dfac.cpp" file).
> I'm sure there will be more changes needed, because I'm not so
> familiar with UNIX.
Thanks.
Yes, more changes are needed. First, one needs to comment out
'#define DOS' in globals.h. Then, (on at least FreeBSD) one needs to
remove '#include "malloc.h", because everything that at one time was
declared in that file is now found in stdlib.h and inclusion of
malloc.h leads to an error. Now, I hit the show stopper:
laptop:kargl[240] g++ -o z -I. dfac.cpp |& more
In file included from actions.cpp:4,
from dfac.cpp:2:
global.h:52:15: error: "or" cannot be used as a macro name as
it is an operator in C++
Steven G. Kargl <s...@removetroutmask.apl.washington.edu> wrote:
> In file included from actions.cpp:4,
> from dfac.cpp:2:
> global.h:52:15: error: "or" cannot be used as a macro name as
> it is an operator in C++
In C, the preprocessor is logically before the compiler, so, as far as
I understand, there is no problem using any C reserved word as a macro
name, as long as you don't need the word.
I know C++ isn't C, but this one surprises me.
Still, if you aren't using the "or" operator, a quick pass through sed
should be able to fix it.
A current user of LRSTAR 3.0 just sent me a Linux source version that
is working with GCC and LLVM. I will do some testing of it this week
and upload it to
