C2 forum
General Category => Ideas => Topic started by: kyle on January 30, 2015, 08:01:28 PM
-
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
-
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..
-
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/ (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.
-
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 (https://github.com/rust-lang/rfcs/pull/560)
It is very long, but I found a lot of interesting information hidden in it.
-
Interesting discussion indeed. Might be difficult to implement in Rust since they are
in 1.0 beta...
Thx for the link.
-
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.