Author Topic: other data type extensions  (Read 8516 times)

kyle

  • Newbie
  • *
  • Posts: 48
    • View Profile
other data type extensions
« 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

bas

  • Full Member
  • ***
  • Posts: 220
    • View Profile
Re: other data type extensions
« Reply #1 on: January 31, 2015, 05:35:27 PM »
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

  • Newbie
  • *
  • Posts: 48
    • View Profile
Re: other data type extensions
« Reply #2 on: February 11, 2015, 06:22:53 PM »
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

  • Newbie
  • *
  • Posts: 48
    • View Profile
Re: other data type extensions
« Reply #3 on: April 04, 2015, 06:13:33 PM »
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

  • Full Member
  • ***
  • Posts: 220
    • View Profile
Re: other data type extensions
« Reply #4 on: April 09, 2015, 10:53:48 AM »
Interesting discussion indeed. Might be difficult to implement in Rust since they are
in 1.0 beta...

Thx for the link.

lerno

  • Full Member
  • ***
  • Posts: 247
    • View Profile
Re: other data type extensions
« Reply #5 on: November 16, 2018, 08:25:53 PM »
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.