Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Problem with Friendly C

blog.regehr.org

Post reply on HN
Print view View original

171–174 of 174 posts

Re: The Problem with Friendly C

#171

Post by GFK_of_xmaspast »

rswier wrote: post #139
GFK_of_xmaspast wrote: post #114

Earlier quoted context omitted.

> RISC created a huge local minimum by speeding up C code to the exclusion of other languages Would you mind expanding this.

In the future I believe you are going to see less emphasis on the aggressive speedup of C code for traditional CPUs. Instead you will see many more gadgets with simpler processors that run C code slower in the effort to save power. GPGPUs and algorithm specific hardware (e.g. video, crypto, network, DSP, neural nets) will fill out the rest of the chip. At some point GPUs will have enough raw power and GP features for…

Your claim was that RISC "created a huge local minimum by speeding up C code to the exclusion of other languages" and it's not at all clear to me what RISC has to do with c, and why other languages are worse off for this.

Re: The Problem with Friendly C

#172

Post by ori_b »

makomk wrote: post #170
ori_b wrote: post #168

Earlier quoted context omitted.

It is, however, what many DSPs do.

Many DSPs don't support byte addressing or arithmetic on 8-bit integers which a huge amount of non-DSP C code relies on. They're not exactly friendly to code not written specifically to run on the DSP. (Or C code in general, for that matter - the reason they have saturating addition and other oddball instructions is because it makes a lot of DSP code faster, but there's no C representation of any of those things.)

And now we get back to the initial quote: "What's your point? If you define a "plain integer addition" to be "wrapping binary two-complement addition", then there isn't, otherwise, there is."

Re: The Problem with Friendly C

#174

Post by Dylan16807 »

ori_b wrote: post #172
makomk wrote: post #170

Earlier quoted context omitted.

Many DSPs don't support byte addressing or arithmetic on 8-bit integers which a huge amount of non-DSP C code relies on. They're not exactly friendly to code not written specifically to run on the DSP. (Or C code in general, for that matter - the reason they have saturating addition and other oddball instructions is because it makes a lot of DSP code faster, but there's no C representation of any of those things.)

And now we get back to the initial quote: "What's your point? If you define a "plain integer addition" to be "wrapping binary two-complement addition", then there isn't, otherwise, there is."

Okay, well since it's my term, I'll make it absolutely clear. The definition is not circular. On those DSPs, plain integer addition is saturating. For x86, so far all evidence points to it being twos-complement.

So the original original quote, "on x86 INT_MAX+1==INT_MIN", is true. As far as I can tell.

Post reply on HN