reply to BCS's reply

actually you meant this:
loop: do{
  for(some loop condition){
    if(something) break loop;
  }
  fallthru_code;
}while(false);
break_out_code;

which I agree solves my problem without gotos, but at the cost of ugliness.  So I
guess the best solution is if a less-ugly way were supported to do this same thing.
We could have a DoItOnce{ ... }  pseudo-loop (which never loops)
syntax to replace do{ ... }while(false);  but that still is ugly.
So your suggestion for this syntax is a good one:

bod: {     // labeled compound statement
   if(cond) break bod;
}

except I do not see the point (or syntactical meaning,
for that matter) of having "continue bod" if bod is not
manifestly a loop.   This simple suggestion of being
able to break out of any block, would
eliminate practically all the remaining gotos in the world.
Excellent idea.

reply to Don Clugston

Yes, the "repeated doubling of wisdom"
bitcount routine you wrote is a good way to do it.
Also, more brute-force, but on many machines faster, is to use
precomputed popcount lookup tables.

Lookup tables can also be used to implement first1, and so
can a "repeated wisdom doubling" approach to implement a binary search.
Another way to do first1(uint x) is first to compute  y=x^(x-1)   which if x!=0
is a uint with a single 1 bit located at the same place as the
least-significant 1 bit in x, and second to hash y, for example
use y%C as the hash function [value in {0..C-1}] and you cleverly choose the
constant C so that this hash function always gives different values
for different y of this form (i.e. perfect hash)
and do a hash-table lookup in a C-entry table.
If I recall right, which I may not, C=63 works.
Unfortunately the "%" is slow on the hardware I used.

All that is suckingly slow compared to hardware support, though.

--

>Are there many applications of [add with carry, etc]
>OTHER than bignum arithmetic? My
>feeling is that you'd always want to do bignum in asm anyway.

>Note that D is a great language for writing asm in; you can have a single source code shared between Windows, *nix, and the new x86 >Macs.

But I want to write PORTABLE, i.e. not-asm, bignum code.
Why is the language denying me the power of the machine?
That is the opposite of its job.  Especially if we are talking
about a power that every machine provides.

It is kind of like saying:  "you can only breathe air from now on, if you use a gas mask.  This is a great advance in technology versus just breathing, so be happy."

The other main application of add-with-carry is to spot integer overflow.

Look, if you just provide, e.g.
    AddWithCarry( in uint x, in uint y, out uint z, out bool carry )
    DoubleMultiply( in uint32 x, in uint32 y, out uint64 z )
        [or maybe two out-arguments, an uper and lower one]
    FullDivide( in uint64 y, in uint32 z, out uint32 quotient,
          out uint32 remainder )
and similar stuff, problem is over.   (Ignore my crappy syntax,
just use this idea but with better syntax.)

Reply to Warren,

> reply to BCS's reply
> 
> actually you meant this:
> loop: do{
> for(some loop condition){
> if(something) break loop;
> }
> fallthru_code;
> }while(false);
> break_out_code;
> 

Oops.

[...]
> So your suggestion for this syntax is a good one:
> bod: {     // labeled compound statement
> if(cond) break bod;
> }
> except I do not see the point (or syntactical meaning,
> for that matter) of having "continue bod" if bod is not
> manifestly a loop.   

The thought is it would be the same as in a while(true), go back to the start of the loop. It could be handy with some kids of loops

// keep (re)doing things in order until all conditions are met.

bod: {
	//somthing
	if(cond1) continue bod;
	//somthing
	if(cond2) continue bod;
	//somthing
	if(cond3) continue bod;
	//somthing
	if(cond4) continue bod;
}

this would work but isn't as informative.

while(true){
	//somthing
	if(cond1) continue bod;
	//somthing
	if(cond2) continue bod;
	//somthing
	if(cond3) continue bod;
	//somthing
	if(cond4) continue bod;
	break;
}


> This simple suggestion of being
> able to break out of any block, would
> eliminate practically all the remaining gotos in the world.
> Excellent idea.

Tabelarising number of nonzero bits in char[256], and
applying it to each 8bit group in 32bit integer, can be quicker.

-- 
Witold Baryluk

== Quote from Warren D Smith (wds@math.temple.edu)'s article
> So your suggestion for this syntax is a good one:
> bod: {     // labeled compound statement
>    if(cond) break bod;
> }

Wrong. The keyword "break" only became a synonym for "goto"; the inherent shortcomings of goto's are not solved this way. (Proof left to the reader.)

>> So your suggestion for this syntax is a good one:
>> bod: {     // labeled compound statement
>>    if(cond) break bod;
>> }

>Wrong. The keyword "break" only became a synonym for "goto"; the inherent shortcomings of goto's are not solved this way. (Proof left to the reader.)

--No, Mr. Anonymous - you're completely wrong.
Gotos can spaghetti, form arbitrary directed network.
Breaks out of blocks, can only get you out
of a block, i.e. moving up in the inclusion hierarchy -
can never go in, i.e. never down in the hierarchy.

I would, however, say that the  bod: { ... }
syntax is psychologically annoying
and I might prefer  bod: block{ ... }
or something.

wds

Witold Baryluk wrote:
> Tabelarising number of nonzero bits in char[256], and
> applying it to each 8bit group in 32bit integer, can be quicker.

It can be (and certainly was always true in the days of the 286), but table lookups always run the risk of falling out of the data cache (and this is something a simple benchmark won't find). On most recent CPUs, cache misses are horribly expensive, and even one cache miss every 1000 calls will easily wipe out any small performance benefits you'd otherwise expect from the table lookup.

== Quote from Warren D Smith (wds@math.temple.edu)'s article
> --No, Mr. Anonymous - you're completely wrong.
> Gotos can spaghetti, form arbitrary directed network.
> Breaks out of blocks, can only get you out
> of a block

I hold my breath!
Do you really declare that the Chomsky hierarchy is wrong---missing
a complete type of infinite languages since ages?

Unfortunately the response to my "suggested improvements to D," oddly, was not uniformly "of course we'll do that immediately."

Let me reiterate my case.  First, D'ers have already agreed by consensus to add
IEEE-float hooks to handle NaNs, rounding, etc.
Good.  That means you already have admitted you
agree with my philosophy that the language
must provide the underlying power of the machine (for any feature
that a large number of machine hardwares now supply) to the user.
Not deny it.
And that means you agree this has to be done even if the syntax
for it might be a little messy. [Which doesn't matter because these
things are used fairly rarely.]

Good.  I'm glad we are in agreement.  I only ask that you now
provide hooks to allow the user to access add-with-carry, cyclic-shift
with or without carry, integer-single-to-doubleword-multiply, doublelength divide,
etc.  Because those things have been available for far longer than IEEE floating
point on far more hardware and are doable with (if anything) less-messy hooks, you
cannot logically provide the IEEE FP hooks but not these; that would be going back
on 50 years of computing wisdom and on your own admitted beliefs.

OK?  There is no question.  D'ers already agreed on this philosophy.

Next, some wondered about popcount and first1 hooks.
But then it was pointed out that, again, my opponents on this
had already lost their case - Intel soon is going to provide
these, again, in hardware, because they agree with me that they
are key instructions.  Good.  Now, referrring again to the principle
(above) that the language must provide (not deny) the underlying
power of the machine to users, again we see you have no
choice but to provide these hooks (unless you choose to go back on
your own admitted philosophy).

After you do these things, you will then be able to add to your D vs X language
comparison charts, the fact D is the only one that does not deny user access to
common hardware primitives.  (And no, sorry:
saying "you can do it by writing your own assembler" does not count as
"we provide access in the higher level language.")

This new feature of your comparison chart will
attract a multitude of users who are impressed with the fact that
finally, the designers of a language are not intentionally trying
to hurt people.

Won't that be nice?

There are even those who would go further and advocate that higher
level languages should even provide the user with access to
features NOT currently hardware-supported, but which should be,
or likely will be in future.   Thus allowing software to
drive the hardware.  Stupendous idea, is it not?
For example, microsoft BASIC provided the user the ability to multiply and divide
numbers, even though that was not available on the 8080 in hardware.  Golly gee.
Wasn't that amazing.
If D wishes to use that idea, then it might even provide
some hooks for some hardware instructions that do not currently exist,
but which have been argued in important papers (which sadly have not
yet penetrated the thick skulls of hardware designers)
to be a good thing which SHOULD exist.
The "dovetail" and "undovetail" instructions would be examples
(known to be useful in some important algorithms...),
and I could mention a few more if anybody shows interest,
e.g. instructions known to be useful to yield sub-NlogN sorting algorthms, etc.

But I do not wish to stretch you too far.  After all,
catching up to Microsoft circa 1980 in the area of language design
ideas, could be too much to ask.  Therefore, I merely ask that
D catch up to the computer hardware available in the 1980s, or
for that matter 1950s.

(Seriously: D seems to me to be pretty much making the right choices
and I've been waiting for a language with that combination of choices for over a
decade, so it'd be a pity to see D fall into the same pit of stupidity as all the
others about such an embarrassingly trivial task as providing a few builtin inline
functions.)

wds

Reply to Warren,

> Unfortunately the response to my "suggested improvements to D," oddly,
> was not uniformly "of course we'll do that immediately."
> 
> Let me reiterate my case.  First, D'ers have already agreed by
> consensus to add  IEEE-float hooks to handle NaNs, rounding, etc.
> Good.  That means you already have admitted you agree with my philosophy that the language must provide the underlying power of the machine (for any feature that a large number of machine hardwares now supply) to the user. Not deny it.

No it dose not. 

> OK?  There is no question.  D'ers already agreed on this philosophy.

This whole thread isn't based on the basic philosophy of D, so I claim that the above is in serious question. (more on this later)

> And that means you agree this has to be done even if the syntax
> for it might be a little messy. [Which doesn't matter because these
> things are used fairly rarely.]
> Good.  I'm glad we are in agreement. 

We are? Starting when? I must have missed that meeting.

[...]
> finally, the designers of a language are not intentionally trying
> to hurt people.
> Won't that be nice?

Only BF, whitespace, intercal and friends TRY to hurt programmers.

> it'd be a pity to see D fall into the same pit of stupidity as all the
> others about such an embarrassingly trivial task as providing a few
> builtin inline functions.)

Firstly, ANY change to the core of a language is by definition non trivial. A better solution is intrinsics, particularly if (in the ops using carry) they take the forms: void adc(uint* a, uint* b, uint* sum, uint count)

As to you claims that not adding these features is counter to the D philosophy, I have written my take on the D philosophy in a paper (link below) and I don't think your claim has support. If I have a erroneous opinion, I would hope some of the long timers would correct me, or if you think that what you are advocating /does/ fall under my opinion of the D philosophy I would entertain you thoughts.

http://www.webpages.uidaho.edu/~shro8822/term_010.pdf
Note: this paper is still in progress.

BCS

> wds
>