🚀 go-pugleaf

In article <PCG.90Aug25160256@athene.cs.aber.ac.uk> pcg@cs.aber.ac.uk (Piercarlo Grandi) writes:
>On 16 Aug 90 19:20:16 GMT, jimad@microsoft.UUCP (Jim ADCOCK) said:
>
>jimad> Actually, the will of this programmer is that C++ compilers generate the
>jimad> fastest and most compact code possible from my class declarations.  It 
>jimad> is not C++ compilers that are tharting this will, but rather people who
>jimad> want to continue using C++ as a C assembly language.
>
>These include Stroustrup, apparently. See the introduction to his first
>C++ book... C++ *has been designed* as an OO MOHLL/SIL.

I think it would be best to let Bjarne speak for himself directly on this 
issue.  My impression is that his second book is carefully and deliberately
worded to allow wide latitude in the implementation of the language.

>jimad> I want to be able to use C++ as a fast, efficient object oriented
>jimad> language.  This requires compilers that have great optimization,
>jimad> and great freedom to optimize.
>
>Why don't you use Self? Objective C or Eiffel? Just because C++ is
>fashionable?

Certainly the fact that C++ is by far the most popular OOPL language has
something to do with it.  [I wouldn't call C++ "fashionable" though -- I'd
call it pragmatic.  Eiffel and Self would be the "fashionable" languages,
to my mind.]  But also the fact remains, if one really wants to write 
real world commercial OO software,  C++ is really the only language
up to the task. [IMHO]

>IMNHO C++ is just about the only OO around with widely available
>compilers designed as a SIL/MOHLL . Let's keep it that way. People who
>want a more applications oriented language should choose something like
>one of the languages above. As soon as GNU CC 2.0 will be released I
>think that Objective C will grow very much in popularity, IMNHO.

Clearly I disagree with your assessment of Obj-C.  And C++.

>jimad> There continues this division between C/C++ people who want a compiler
>jimad> to "do what I say" verses "do you best optimizations."  I think this
>jimad> issue should be addressed in the marketplace -- not in the language.
>
>This of course kills any idea of portability. You programs start to have
>semantics that depend, by construction, both on the compiler and the
>language. This is IMNHO *very* bad, vide the abominable pragma pandora
>box of Ada and Ansi C. It may be very good for compiler vendors, though,
>especially those that have or think will have a large market share, and
>want to get entrenched into it. Thank goodness AT&T does not reason that
>way, because they are too large and diverse an organization themselves.

I think you have this backwards.  In the absense of good optimizers, people
have to program around the limitations of their individual compilers, and
hand optimize code for a particular situation, keeping it from being
reusable.  I don't particularly like pragmas, but I think they may be an 
acceptable compromise to warn a compiler when people insist on writing hacks
that rightfully would fall outside the language.  Companies that design
portable compilers should tend to show a bias towards keeping the language
such that making portable compilers is easy.  Companies that design compilers
for a particular CPU or OS should tend to show a bias towards making the
language highly optimizable.  We should not be surprised if a tension 
between these two goals shows up as part of the standardization process.
[standard disclaimer]

>jimad> If you want to use C++ to play with machine registers, then
>jimad> portability is not an issue to you anyway.
>
>Ah no, not so easy. One can provide, thanks to the wonders of separate
>compilation or conditional preprocessing, both a slow portable version
>and a fast one that will not work on every implementation, but is still
>expressed as much as possible in the base language.

Agreed.  But does such code actually party based on the layout of a particular
CPU's registers or ports?  -- I think not.

>jimad> Again, why should everyone's C++ compiler have to generate slower,
>jimad> more memory intensive code in order to meet the needs of people who
>jimad> feel they want to maintain intimate control over their compiler?
>
>Maybe because the language has been designed for the latter group...

Hm.  I would think that now that C++ is the leading OOPL it needs to try
to meet the needs of the majority of its users.  I would not think that
the majority of people need or want to maintain intimate control of their
compiler.  I'd think the average OO programmer would be working on a much
higher level, using libraries others provide to do the bit twiddling.
Once these low level libraries are written, the many others can build on
these efforts.

>And because many times the compiler cannot understand the program better
>than they do anyhow, or requiring the compiler to do it is not a win-win
>situation, e.g. results in larger, slower, less reliable compilers.

If this opinion is correct, why would it not win in the marketplace?
Why cannot C++ programmers just say, hm, FuzzCo's Ultra-C++ compiler isn't
worth the time/size/money or complexity.  I'll just use this TinCo Tiny C++
compiler instead?  Whats wrong with letting the marketplace decide these
tradeoffs?  Why is it necessary to force your particular engineering 
design tradeoff beliefs into the language definition itself?

>Consider also the conclusion that you and Guilmette seem to be reaching:
>the compiler may reorder at will by default, as long as there is some
>mechanism to override it. This seems the best solution, as long as you
>do not see the additional cost in complexity/unreliability of the
>manual, of the compiler, of the program build process. You have to weigh
>these things carefully, and if you do not, you go down the slippery path
>Ansi C has gone.

Actually, my conclusion is not that compilers may reorder at will.  My
conclusion is that compiler designers should have the freedom to decide
these issues for themselves, and that C++ programmers should have the
freedom to choose the compiler that then best serve their needs.
Nothing I have proposed forces a vendor to offer a large, complicated 
compiler.

Again, compilers already have the right to almost completely reorder a 
structure at will.  The *only* constraint in E&S is that within a labeled
section, member variables declared later will be places at "higher" addresses.
The reason given for this constraint is backwards C compatibility.  Well,
the constraint is so weak as to offer little in backwards C compatibility.
So my suggestion is to remove it, or to relegate it to those features of
the language specifically addressing backwards compatibility.  To my eye,
having both the extern "C" construct, and a separate field ordering 
restriction applied accross the language, looks like a simple historical
oversight, that should be fixed.

>So, are today's C/C++ multimegabyte compilers significantly more
>reliable and faster and generate better quality code than those that run
>in 64KB[+64KB]? IMNHO no, or at least not enough that the changed
>pragmatics should influence for design of the language (as has happened,
>for the worst, with Ansi C).

Then don't buy or use such compilers.  Use one that suits your fancy.
I don't propose to try to force a compiler you don't like on you.
Why do you want to force your particular compiler design beliefs onto
the compiler I would use?  Again, my proposal is to leave this issues
to the sensibilities of the compiler designers, and the power of the 
marketplace.  Over the near term, I'd be very surprised if any compiler
diverges too far from the cfront object model, because the cfront object
model represents the only object model that many programmers know. So there
would be great market skepticism to a compiler that introduced a very 
different object model.  However, as time goes on, other OOPLs are going
to demonstrate very different object models, and I claim we want C++ to
be specified with the freedom to allow compilers to incorporate the best
of those new object models.  And/or to allow C++ compilers be designed
simply to allow compatibility to these other object models.

>But maybe I am wrong, and the relative cost of compile time resources
>(time, space, programmer confusion, reliability) vs.  runtime speed have
>changed so much that a modest increase of the latter can be economically
>bought at the price of a large increase of the former.

I guess from my perspective, there is clearly not one answer to this question.
The tradeoff between development costs verses runtime costs is very much
a function of the number of units of your program you intend to produce.
If only a couple copies of a program are to be created, development cost
is paramount, and runtime cost is typically unimportant.  If a company
makes millions of copies of a programmer however, runtime costs outweight
all other factors.  A company that failed to shave the last few seconds
from their software in that situation would be costing society thousands,
if not millions of dollars in wasted user productivity.

In the first scenerio, a C++ programmer might want to use an p-coded
C++ implementation that follows a minimal recompilation strategy.  This
might be accomplished by inheriting via reference, not embedding objects,
and tagging any newly declared members on the end of an objects' section.
This is one object model totally different than the cfront model.

In the second scenerio, a highly optimizing compiler might be used.  Pragmas
might be used to indicate when constants aren't.  Pragmas might be used to
indicate when a class is a leaf class.  Compilations might be optimized on
a module global basis.  Smart linkers might winnow out vtable indirect calls.
Fat tables, or tricks might be used.  Fields might be reorganized based
on profiling information.  This would also lead to an object model very
different from cfront.

Thus, I don't believe one object model spans the needs of all C++ users
[nor all systems C++ might run on -- such as a Rekursiv-like machine,
or a Lisp-like machine, or a Smalltalk-like machine]  So I believe it 
would be very short sighted to try to specify the C++ language strictly
around a cfront-like object model.  Let's leave our options for the future
open.