Subject:
|
Re: OO programing in RCX
|
Newsgroups:
|
lugnet.robotics.rcx
|
Date:
|
Wed, 12 Jan 2000 04:22:37 GMT
|
Viewed:
|
1658 times
|
| |
|
|
In article <387BE637.84D065B1@noga.de>, "Markus L. Noga" <markus@noga.de> wrote:
> > Ironically, the NQC compiler itself is very OO.
>
> Interesting. Most compilers aren't - which is very bad for maintenance
> if they're written by hand. But then, there are generators for almost
> every stage of a compiler now.
OO works very well for things like a parse tree. I can add a new
statement and just add its rules for semantic checking and code
generation...all within its own class.
I think part of the problem is that compiler design is a very heavily
studied topic, with lots of practice dating to before OO was in vogue. As
a result, there are tons of examples how to do it without OO, but very
little on how to use OO in a compiler.
> I was wondering, did you use generators in writing nqc? What kind of
> intermediate representation are you using? Code-generator templates are
> probably tricky, considering the bytecodes...
I'm using flex to generate the lexer, and bison to generate the parser.
Because I'm using a preprocessor, the parser doesn't sit directly on top
of the lexer - there's a preprocessor stage between them.
Also the preprocessor needed its own parser (for #if) which is fairly
simple recursive descent parser built by hand. Expressions (for #if
directives) are parsed using a hand built operator precedence parser.
Neithr of these tasks were complicated enough to warrant creating another
bison generated LALR parser.
Code generation is completely custom. Optimization is done in the same
pass as code generation. Originally the language was pretty simple (no
expression evaluation, no temp variables, no function calls) so this was
easy to do. As the langauge has grown, the code generation is starting to
get a bit unwieldy. I suspect I'll have to go to a more traditional
intermediate code generation with a separate optimization stage pretty
soon.
> On a different note, we recently made a comparison of several
> implementations of standard compiler data structures, e.g., symbol and
> definition tables, syntax trees etc. Plain old C came out two times as
> fast as standard C++, and over three times as fast as STL code. Of
> cause, this only amounts to anything if you're planning on compiling
> several thousands of lines of code ;-)
I've stayed completely away from STL for NQC - mostly because when I
started on NQC there was a lot of inconsitency in standard library
implementations across compiler vendors. There are still some annoying
problems out there today.
It really wasn't that big a deal since perhaps the two things I'd have
used the most were list and vector - and I already had suitable
templatized container classes of that sort. At some point I'll probably
get rid of my vector class in favor of the standard one, but I'm still
going to keep my list class - it has very different semantics than the
standard library (1).
My symbol table probably isn't too bad performance-wise. Perhaps the
worst thing is that it relies fairly heavily on allocating small chunks of
memory (though not nearly as much as STL based stuff). I had a different
symbol table implementation that allocated large pages at a time, but in
the end I decided that simpler more maintainable source code was much more
important that runtime performance. I think Knuth said something to the
effect that premature optimization was the root of all evil (I'm
paraphrasing a bit).
Dave Baum
--
reply to: dbaum at enteract dot com
|
|
Message has 1 Reply:
 | | Re: OO programing in RCX
|
| Dave Baum schrieb: (...) Yes, definitely so. Many concepts in parser generators are actually OO (bison result types, for example), but they aren't implemented that way. (...) Prof. Goos rather convincingly advocates generation as the do-all and (...) (25 years ago, 12-Jan-00, to lugnet.robotics.rcx)
|
Message is in Reply To:
| | Re: OO programing in RCX
|
| I should probably mention again that legOS supports C++, and supports it even better if you add void*builtin_new(size_t n){return malloc(n)}; to the appropriate library, as v0.3.0 will. The rest of this is off-topic. Dave Baum schrieb: (...) (...) (25 years ago, 12-Jan-00, to lugnet.robotics.rcx)
|
14 Messages in This Thread:
 
 
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
This Message and its Replies on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
