🚀 go-pugleaf

In article <7935@scolex.sco.COM> seanf (Sean Fagan) writes:
> In article <9363:Sep2521:41:1290@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes:
> >  quickpick
> >  fast(define builtin_bitcount 0)
> >    count = bitcounts[j & 65535] + bitcounts[(j >> 16) % 65535];
> >  fast(define builtin_bitcount 1)
> >    unsigned long i;
> >    for(i = j;i;i >>= 1) count += (i & 1);
> >  endquickpick
> 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.

> The Elxsi has an instruction for passing a message (up to 836 bytes, I
> think) to a "port", which is usually another process (yet need not be).  Are
> you going to straddle your "language" with the semantics of this
> instruction, simply because someone may find it useful?

Of course not! What would be the point of that? The compiler should be
able to use the instruction if at all possible, but nothing in the
language changes. What we're trying to do here is let a language be
downward-extensible without losing portability at all.

> Now, all that said:  C has the #ifdef route, which is close to what you
> want.

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.
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.

---Dan