Re: Compiler requirements...help needed

"Sebastian Moleski" <smoleski@surakware.com>
4 Nov 2000 01:39:38 -0500

          From comp.compilers

Related articles
Compiler requirements...help needed neal.a.benedict@intel.com (Benedict, Neal A) (2000-11-01)
Re: Compiler requirements...help needed smoleski@surakware.com (Sebastian Moleski) (2000-11-04)
Re: Compiler requirements...help needed tnaran@direct.ca (Travers Naran) (2000-11-04)
Re: Compiler requirements...help needed rbenedik@fsmat.htu.tuwien.ac.at (Ronald Benedik) (2000-11-05)
Re: Compiler requirements...help needed clc5q@cs.virginia.edu (Clark L. Coleman) (2000-11-07)
| List of all articles for this month |

From: "Sebastian Moleski" <smoleski@surakware.com>
Newsgroups: comp.compilers
Date: 4 Nov 2000 01:39:38 -0500
Organization: T-Online
References: 00-11-018
Keywords: design
Posted-Date: 04 Nov 2000 01:39:38 EST

Hi,


I'm glad that some "big company" comes by here, as well. This gives me
the feeling that maybe they actually do care about their
customers. Not just in their marketing.


Well, I have been working on a compiler for a self-designed
programming language for about one and a half years now. One of our
goals is that the compiler would emit the same code for various
languages. So, besides our language, the compiler could also read,
say, C, C++ and Fortran code. Also, we wanted to have a way of
reverting that intermediary code to source in any of the above
mentioned languages. Of course, this is a rather complicated goal to
achieve but we are sure we will reach it. Someday. Eventually. What I
am saying is that if your compiler produces some indermediary code,
document it. And don't get hooked up in compatibility to COFF/OMF if
it doesn't fit your needs. To write linkers is not all that
difficult. And with the global availability of the Internet, spreading
a new program not all that difficult. Just don't cut down your
expectations by limiting them to the existing tools. Rather do it the
opposite way around.


Another hint: don't use lex/yacc or any other parser generator. I like
to know and have control over my code. And I like to come to solutions
I've created myself. We use an object-oriented design, having classes
for the compiler, parser, lexer, expressions, statements, etc. Try to
use something similar and you will be amazed at how easy extensions
are. We are amazed ourselves.


Well, that's all so far. If you want any more comments on this, just
contact me via e-mail.


Regards,


Sebastian Moleski


> [I'd like a compiler that can compile programs of any size in
> arbitrary combinations of C, Pascal, Perl, Common Lisp, and Intercal in
> under a second, produce object programs of under 100 bytes with runtimes
> too short to measure, and fix any bugs in the source code while it's
> compiling them. Perhaps you could give us more hints about what areas
> you were planning to work on. -John]
P.S. And make some coffee it must be able to, also. :)


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.