🚀 go-pugleaf

In article <7950@scolex.sco.COM> seanf (Sean Fagan) writes:
> In article <29047:Sep2816:51:1290@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes:
> >> Ugh.  Are you then going to standardize *everything*?
> >What are you talking about? The only thing added to the language is the
> >quickpick control structure. All I'm doing is letting the programmer
> >give the compiler a much better chance to optimize a section of code.
> Uhm... where are you going to define the names that are used?

What names are you talking about? The language is not extended by the
compiler.

> Or is the
> compiler supposed to go through your "worst-case" one, analyze it, and see
> which instruction matches it most closely?  If it could do that already, you
> wouldn't need to bother with your "quickpick" thingy.

Huh? The compiler already converts any given sequence of code into
machine instructions as well as it knows how. quickpick just lets the
programmer give the compiler several alternatives. There's no way to do
this currently.

> If the "names" are going to be "standardized" (which is what I was referring
> to), you're going to have a real mess on your hands, which is why I went
> into the example about the elxsi et al.

Agreed, that would be a real mess, like the current ifdef situation. See
my first quickpick example.

> >No, it isn't, for the several reasons I explained in the first article
> >of this thread. ifdefs are clumsy to define, and they guarantee that
> >your program will run poorly when the hardware changes under your nose.
> So will your method.  You would have to recompile.

Yes, I'm aware of that; programs are almost always recompiled for new
hardware. The point is that you don't need the original programmer
slobbering over each new chip to figure out whether it's faster with
algorithm X or algorithm Y. You let the compiler do the job for you.

> If you do something like:
> 	#ifdef	BIT_COUNT_IN_HARDWARE
> 		__builtin_bitcount (whatever);
> 	#else
> 		whatever
> 	#endif
> what is the difference between *that*, and your method?  Other than niggling
> little details?

Namespace problems! Lack of portability! Decentralized language
extensions! The difficulty of defining every single ifdef on every
single machine! Don't you realize that this is a problem?

> >They require that someone who wants to install the software on a new
> >machine figure out each one of your ridiculously many ifdefs. That is
> >not the portable downward extensibility that we want.
> Your method requires lots of things, too.  Generally, though, the person who
> builds the compiler would figure them out, not necessarily the installer.
> For example, in <stdlib.h> (or something like <stdext.h>, I guess), with the
> correct defines for the machine.  No more difficult than installing a libc.
> For most people, that is.  Maybe not you.

At the risk of being overrepetitively redundantly redundant: Think about
managing the namespace. How do you plan to tell all the compiler writers
around the world what symbols they should define? Do you plan to fix a
single set and let this form of optimization stagnate? Do you want
namespace anarchy? Will you hold an annual seance to resolve these
problems? What will you do when the number of symbols balloons? Do you
seriously believe that each vendor is going to define a thousand other
symbols saying ``no, I don't support that other vendor's optimizations''
when only ten or twenty optimizations are relevant locally?

The current C situation makes it annoyingly difficult to write portable,
efficient code. For most people, that is. Maybe not you. Maybe you think
that it's reasonable for each package to define a new set of symbols for
the installer to suffer through. I don't.

---Dan