Subject:
|
Re: OO programing in RCX
|
Newsgroups:
|
lugnet.robotics.rcx
|
Date:
|
Wed, 12 Jan 2000 13:23:36 GMT
|
Viewed:
|
1704 times
|
| |
|
|
Dave Baum schrieb:
> 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.
Yes, definitely so. Many concepts in parser generators are actually OO
(bison result types, for example), but they aren't implemented that way.
> 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.
Prof. Goos rather convincingly advocates generation as the do-all and
cure-all here in Karlsruhe. Great maintainability, a supportive formal
framework and less code to write - and less code means less errors.
> 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.
I thought so, from the way NQC evolved. It was a one-pass compiler
initially, wasn't it? Did you already chose an intermediate
representation?
Incidentally, we're developing a compiler for a subset of C as a
University project, mostly to check out FIRM, a new intermediate
representation using single static assignment form and automatic
generation of phi functions. The chair hasn't decided on a target
machine architecture yet, this being educational and all, but it will
probably be JVM bytecode or IA32 assembly, not RCX bytecode.
There are several code generator generators out, too.
> 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.
Like, part of string streams described in Stroustrup are still
conspicuously absent from gcc? Many simple types need their own hash
functions, because the hashed containers don't define them? I know what
you're talking about.
> 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).
I have a heap class implemented in C, which is used to allocate symbol,
definition and string table memory, as well as abstract structure tree
nodes. That way, I get fast allocation, low overhead, low footprint and
good maintainability. Another plus, AST memory can be freed at once
without a graph traversal when the intermediate representation has been
created.
Still. "When to optimize: 1. Never 2. As late as possible." I don't
remember who coined that one, though.
Markus.
|
|
Message has 1 Reply:
 | | Re: OO programing in RCX
|
| (...) If I were writing NQC from scratch, I'd agree. However, several years ago I was writing a preprocessor and bison wasn't available to me, so I hand-coded the parser. When NQC was started, I just reused about 90% of this parser. Of coruse, along (...) (25 years ago, 13-Jan-00, to lugnet.robotics.rcx)
|
Message is in Reply To:
| | Re: OO programing in RCX
|
| (...) 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 (...) (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
|
|
|
|
