Forum Rule: Always post complete source code & details to reproduce any issue!
Results 1 to 15 of 15

Thread: datatypes bit depth

  1. #1

    datatypes bit depth

    It really sounds like a silly question and it probably is but i think it will be helpfoul for coding newbies (like me) to create a small table to summarize the various datatypes bit depth for the teensy 3.0, i'm porting a sketch from arduino to teensy and i'm full of doubts about the bit depths difference between the arduino and the teensy.

    Thanks !

  2. #2
    Senior Member+ MichaelMeissner's Avatar
    Join Date
    Nov 2012
    Location
    Ayer Massachussetts
    Posts
    3,846
    On 32-bit ARM systems like Teensy 3.x/LC:

    • char, signed char, and unsigned char are 8 bits;
    • The plain char type is unsigned by default;
    • short and unsigned short are 16 bits;
    • int and unsigned int are 32 bits;
    • long and unsigned long are 32 bits;
    • pointers are 32 bits;
    • long long and unsigned long long are 64 bits;
    • float is 32 bits;
    • double is 64 bits;
    • long double is 64 bits.


    On 8-bit AVR systems like Teensy 2.0, Arduino Uno, etc:

    • char, signed char, and unsigned char are 8 bits;
    • The plain char type is signed by default;
    • short and unsigned short are 16 bits;
    • int and unsigned int are 16 bits;
    • pointers are 16 bits;
    • long and unsigned long are 32 bits;
    • long long and unsigned long long are 64 bits;
    • float is 32 bits;
    • double is 32 bits (this violates ISO C/C++);
    • long double is 32 bits (this violates ISO C/C++).

  3. #3
    Senior Member
    Join Date
    Apr 2016
    Location
    St. Petersburg, FL
    Posts
    209
    I have several sketches that have been moved from a Nano and Mega to a Teensy 3.2. I've adopted the terminology intxx_t/uintxx_t to be sure it works on both boards. The value of xx can be 8, 16, 32, or 64.

  4. #4
    Senior Member ninja2's Avatar
    Join Date
    Aug 2016
    Location
    Adelaide, Australia
    Posts
    151
    helpful summary, thanks

    Do long long and long double mean the same thing in ISO C/C++?

  5. #5
    Senior Member+ MichaelMeissner's Avatar
    Join Date
    Nov 2012
    Location
    Ayer Massachussetts
    Posts
    3,846
    Quote Originally Posted by ninja2 View Post
    helpful summary, thanks

    Do long long and long double mean the same thing in ISO C/C++?
    long long (which is an integer type at least 64 bits) was not in the original ANSI C (C89) and ISO C90 standards. The next version of the C standard (C99) did have long long.

    I don't have a copy of C++89, but long long is in the C++11 and C++14 standards.

    long double (which is a floating point type that might have more precision and/or exponent range than double) was in the orignal C89/C90 standards. As I mentioned in my first reply, the AVR double does not meet the ISO C/C++ standards because it is only 32-bits.
    Last edited by MichaelMeissner; 09-04-2016 at 02:54 AM.

  6. #6
    Senior Member ninja2's Avatar
    Join Date
    Aug 2016
    Location
    Adelaide, Australia
    Posts
    151
    so I guess that's a no, with clarification... thanks!

  7. #7
    Thanks !!! Very helpfoul I thinik this should be put someware in the teensy 3.x product details.

  8. #8
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    12,340
    Added MM's post to the WIKI links list: Wiki-Coming-Please-link-worthy-posts

    As Artic_Eddie notes in post #3 intxx_t/uintxx_t gives explicit well defined types, and float is the best supported type for Teensy floating point - single precision floating point on T_3.5 and T_3.6 is native and well emulated on the prior T_3's.

  9. #9
    Senior Member+ MichaelMeissner's Avatar
    Join Date
    Nov 2012
    Location
    Ayer Massachussetts
    Posts
    3,846
    Quote Originally Posted by Arctic_Eddie View Post
    I have several sketches that have been moved from a Nano and Mega to a Teensy 3.2. I've adopted the terminology intxx_t/uintxx_t to be sure it works on both boards. The value of xx can be 8, 16, 32, or 64.
    For variables that iterate over arrays, you want to use the size_t type, which is an unsigned type large enough to iterate over array indexes. On 64-bit systems, int is typically 32-bits, and the 64-bit system may need to issue extra instructions to do 32-bit arithmetic in 64-bit values. While on a 32-bit system like Teensy, you can use int or unsigned, it is a useful habit to get into in case your platform of choice changes over the years.

    If you need a signed variant, there is ssize_t, which is the same size as size_t, but signed.

    If you need integer types that are the same size as void * pointers, there are the intptr_t and uintptr_t types. On most systems void * is the same size as other object pointers, but there have been systems in the past that void * was a different size or representation than int *. And also, there have been systems where a pointer to a function is different than a pointer to an object.

    If you want to use the largest integer type supported by the compiler, there are the intmax_t and uintmax_t types.

    If you want a type that is at least <n> bits, but is fast, you would want to use int_fast<n>_t and uint_fast<n>_t (replace <n> with 8, 16, 32, or 64).

    If you want a type that is at least <n> bits, but may be larger, you would want to use int_least<n>_t and uint_least<n>_t (replace <n> with 8, 16, 32, or 64).
    Last edited by MichaelMeissner; 09-04-2016 at 02:08 PM.

  10. #10
    Senior Member
    Join Date
    Jan 2013
    Posts
    843
    Quote Originally Posted by MichaelMeissner View Post
    If you need a signed variant, there is ssize_t, which is the same size as size_t, but signed.
    It's a very lousy type, it's not even standard C or C++. It's defined by Posix:
    <<< The type ssize_t is capable of storing values at least in the range [-1, SSIZE_MAX]. >>>

    Don't use it, unless you need to interface with other code using it.

  11. #11
    Senior Member+ MichaelMeissner's Avatar
    Join Date
    Nov 2012
    Location
    Ayer Massachussetts
    Posts
    3,846
    Quote Originally Posted by tni View Post
    It's a very lousy type, it's not even standard C or C++. It's defined by Posix:
    <<< The type ssize_t is capable of storing values at least in the range [-1, SSIZE_MAX]. >>>

    Don't use it, unless you need to interface with other code using it.
    While it isn't part of ISO C++, it is frequently useful to have a signed variant of size_t that is the same size. And given the Arduino libraries use newlib with also supports Posix, it should be safe to use.

    As I said on 64-bit platforms, size_t is usually the preferred unsigned integral type, and ssize_t would be the preferred signed integral type.

  12. #12
    Senior Member
    Join Date
    Jan 2013
    Posts
    843
    Quote Originally Posted by MichaelMeissner View Post
    While it isn't part of ISO C++, it is frequently useful to have a signed variant of size_t that is the same size.
    But that's not what you are getting. It can be longer (quotes from "Open Group Base Specifications Issue 7"): "The wording is such that an implementation may either choose to use a longer type or simply to use the signed version of the type that underlies size_t. ..." It may or may not be able to represent size_t values: "It is recognized that some implementations might have ints that are smaller than size_t.".

    The guaranteed negative range is -1. There is a macro for the positive range SSIZE_MAX, there isn't one for the negative range (SSIZE_MIN is missing).

    IMO, intptr_t, ptrdiff_t or one of the int*_t types are a better choice (except when interfacing with code already using ssize_t).

  13. #13
    As far as I see it from my uneducated view: Main intention to have ssize_t is the use as a return type to offer a size_t type return value with the addition of -1 to denote some error condition. Following that line of thought it would need to be 1 bit wider than size_t, but in the real world this poses all kinds of issues. One way around this is to use in-out parameters of size_t and have a dedicated return value for ok/error.

  14. #14
    Junior Member
    Join Date
    Apr 2020
    Posts
    12

    So many thanks !

    Quote Originally Posted by MichaelMeissner View Post
    On 32-bit ARM systems like Teensy 3.x/LC:

    • char, signed char, and unsigned char are 8 bits;
    • The plain char type is unsigned by default;
    • short and unsigned short are 16 bits;
    • int and unsigned int are 32 bits;
    • long and unsigned long are 32 bits;
    • pointers are 32 bits;
    • long long and unsigned long long are 64 bits;
    • float is 32 bits;
    • double is 64 bits;
    • long double is 64 bits.


    On 8-bit AVR systems like Teensy 2.0, Arduino Uno, etc:

    • char, signed char, and unsigned char are 8 bits;
    • The plain char type is signed by default;
    • short and unsigned short are 16 bits;
    • int and unsigned int are 16 bits;
    • pointers are 16 bits;
    • long and unsigned long are 32 bits;
    • long long and unsigned long long are 64 bits;
    • float is 32 bits;
    • double is 32 bits (this violates ISO C/C++);
    • long double is 32 bits (this violates ISO C/C++).


    Just perfect !

  15. #15
    Senior Member
    Join Date
    Jul 2020
    Posts
    173
    I always thought "long long" should have been called "extremely long" instead.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •