other data type extensions

[kyle]

In a previous post, I noted that specifying the endian-ness of a variable would be very useful.  When doing DSP-like operations in multimedia code, saturating arithmetic would be very useful.  It is possible to wrap this in a short inline function or macro in C, but then you will not use special instructions in CPUs that have them.

I thought about underflow/overflow traps too, but that is more than just a small extra type modifier.

Other thoughts?

Best,
Kyle

[bas]

My goal with C2 is to stay compatible with the C language. Adding underflow/overflow traps
would definately break that I think. Just as garbage collection, classes etc..
I wonder if there are any programming languages targetting DSP's..

[kyle]

Re: underflow/overflow

Yes, I agree.  Those are problematic because they start forcing traps.  That was my point that they are more than just a type modifier.

The only language I know of that is targeted at DSPs are dialects of C.  However, you get a lot of new keywords and #pragmas :-)

Here http://danluu.com/integer-overflow/ is an interesting blog post on the real cost of overflow checking.  Interesting results.  They are much lower than I thought.  I still do not think they belong in a C-like language, but that is because the logic behind overflow/underflow handling is not obvious in such a language.  At that point you start to need exceptions or some other means to handle overflow/underflow. 

[kyle]

There is a very long thread on the Rust RFC GitHub issues tracker that has some interesting discussion (as well as some heated discussion) about overflow checks etc.

https://github.com/rust-lang/rfcs/pull/560

It is very long, but I found a lot of interesting information hidden in it.

[bas]

Interesting discussion indeed. Might be difficult to implement in Rust since they are
in 1.0 beta...

Thx for the link.

[lerno]

What could be done for C2 is to add a few things:

1. A way to ask (at compile time) what sort of overflow behaviour the processor supports.
2. A way to ask (at compile time) endianness of the processor.
3. A way to do wrapping add as built-in function
4. A way to do trapped add as built-in function
5. A way to ask (at compile time) how fast the a certain type of add is (fast, slow, emulated)

Those would only need to be macro defines.