"James Kanze" <
[email protected]> wrote in message
On Jun 1, 10:44 pm, "JohnQ" <
[email protected]>
wrote:
On May 30, 6:22 am, "JohnQ" <
[email protected]>
wrote:
" [It would help if you'd use standard Internet protocol
citations. It's hard to follow who says what in your
postings.]"
For some reason, my newsgroup reader doesn't insert the >
symbols in certain responses (on yours for instance!). I don't
know why!
"Then it's time to change newsreaders. Even Google gets this
right."
I'll keep an eye on it now, but I think it may only be happening
in response to your posts.
"No one else seems to have that problem."
Weird huh?
"Most programs are IO bound, and of course, they won't use
optimization. But you don't have to be in scientific computing
to find exceptions."
So, optimization can be avoided is what you're saying.
"Sure. In practice, you don't activate optimization unless you
need it. Many systems are IO bound, and there's no point in
being complicated when you don't have to be."
Well that was part of _my_ point to begin with.
"But you don't have any more guarantees. I'm most familiar with
the Posix environment, and Posix compliant compilers give the
guarantees you need, regardless of optimization. If you don't
want things like write order rearranged, you need special
hardware instructions---the compiler inserts these where needed
according to the guarantees it gives, and not otherwise.
Regardless of the level of optimization."
That's the theory at least.
"In practice, as well."
You're making the assumption that the additional complexity of
optimization added on top of the non-optimizing compiler does
not introduce any more potential for error (MT case or other).
I would err toward the risk-averse side OTOH.
"Optimization is an additional complication for the compiler, and
so does increase the risk of error. But that's independant of
multi-threading or not---I don't think I've ever seen a case
where optimization caused a threading problem that wasn't
already there before."
OK, you agree then, good. Same thought exactly.
Better safe than sorry. Turning on optimization for testing
whether funny things happen is a good idea though.
[...]
"It's really purely annecdotal, and certainly has no effect on
how you write C++ or develop programs. (That doesn't mean that
it is uninteresting. Just that it doesn't have any real
financial value, that a company would pay for.)"
Building a compiler for a new language?
"I don't know many companies in that business
. But seriously,
you don't hire beginners for that. You hire people who know
compilers."
**********************
Isn't it dependendent on how complex the language is?
Certainly. It takes about six man-months to develop a C
compiler front-end (without optimizer); I'd guess off hand that
it takes at least four times that for C++, maybe even a lot
more.
Are front ends or back ends harder to create?
They're different. A good optimizer can be extremely difficult.
The real difference, perhaps, is that having chosen your
language, you've chosen the complexity of the front end; the
complexity of what follows depends largely on how much you want
to optimize. Traditionally, you'd count on about two man-months
to develop a simple back-end, but on a modern pipelined
architecture, such a back-end is likely to have very poor
performance.
Don't both of those exist premade already (EDG?).
EDG will sell you a front end for some languages, probably for a
lot, lot less than it would cost you to develop it yourself.
There are still reasons why some compilers don't use it,
however: g++, of course, because it is not GPL; Sun and
Microsoft, probably because they want to maintain more control
in house; other companies for perhaps other reasons.
</QUOTE>
So, ... if I have a "simpler language" and don't need optimization,
my implementation costs will be WAY less (than C or C++,
especially the latter).
The ideal would be to be able to feed
a grammar, or better yet, parameters, to a tool and have it spit out
the compiler: an end to "languages of great complexity"? There's
a research potential: "Investigation of Parametric Language
Specification and Implications on Compiler Generation". The
intermediate code for the purposes of the research could be C++
(actually, very controlled constructs and usage of C++).
John
