1-Bit and 24-Bit Integer Variables, Please

Hi,

I think that in practice, adding a 1-bit with bit-packing as well as an 24-bit variables would be great additions, not only to Arduino but general purpose programming as well. While the user can manually work with each, code readability suffers.

There are a great many single-bit variable uses. The Arduino has both a limited program and variable space, and having a solid and efficient single-bit library support would save on memory. Basically, the user could specify an array of bits, such as:

bits options[120];

And set a bit:
options[5]=1;

Or the user could specify single-bit variables:

bits dog_walked, trash_out, teeth_brushed;

And then set a bit:
dog_walked = 1; // Or true, if you will

Both RGB color and DAC sound often use 24 bits. For many applications, 16-bit integers are too small, while 32-bit numbers are too slow. They could be called Int24, or better-yet, or "unsigned mid" or something like that, referencing "long".

In Arduino's microcosm, it seems like there are almost inexhaustible resources for getting anyone's device going. What I am asking for is a fundamental improvement for the language that will likely benefit all users.

Thank you for your consideration,
-- BrendaEM

Arduino uses standard C/C++, and thus is significantly at the mercy of the standards for those languages.
C is ... quite opposed to data types that you can't have a pointer to (preferably with hardware support), so this eliminates the possibility of 1-bit data types. (There was a brief window where some ARM chips supported pointers to single bits, but no one jumped on that enough for compiler vendors to notice.) You should be able to find assorted C++ libraries that support bit groups as objects of some sort, and would allow a syntax similar to what you suggested.

On the plus side, avr-gcc has supported 24bit integers for several releases now, and you should be able to "just use" the appropriate data types "__int24" and "__uint24", even in arduino code.

I don't the there is any benefit to hiding behind C's shadow.

  • Arduino already uses the Byte data type, which is non-standard, but helpful
  • Arduino doesn't require pointers, which is certainly not standard, but good.
  • C does not have many of the hardware specific statements that Arduino uses.
  • Arduino's "Setup" functionality is non-standard, but helpful.

Beyond the code efficiency and compactness gain, if 24 bit, and compacted 1bit data types were in the Arduino library the code that uses it would be much more readable.

if 24 bit, and compacted 1bit data types were in the Arduino library

Maybe you missed the part about 24 bit datatypes already being implemented.
They just need a few extra overloads to things like the print methods to make them easier to use.

BrendaEM:
I don't the there is any benefit to hiding behind C's shadow.

It's not a matter of "hiding behind C's shadow". After some minimal preprocessing, the .ino files of Arduino sketches are compiled as C++, using a standard C++ compiler.

BrendaEM:
Arduino already uses the Byte data type, which is non-standard, but helpful

Non-standard, yes, but it's just a typedef:

typedef uint8_t byte;

BrendaEM:
Arduino doesn't require pointers, which is certainly not standard, but good.

C and C++ don't require pointers either, so that is definitely standard. It's a feature of the language. You can use it if you like.

BrendaEM:
C does not have many of the hardware specific statements that Arduino uses.

They're just functions from a library. It might not seem like it because you don't need to add an #include directive to the .ino file. That's because it's automatically added during sketch preprocessing.

BrendaEM:
Arduino's "Setup" functionality is non-standard, but helpful.

It's just a function called from main():

main() is hidden away in the core library, but really it's just standard C++.

I was never keen on Arduino's choice of "byte" as "uint8_t" - it confuses the Java programmers.

It's interesting because the origin of Wiring's (and thus Arduino's) byte type is the Processing language, which is based on Java and has the same signed byte type as Java. My understanding is that Wiring's goal was to provide a familiar programming experience to Processing users, so the same types and API were used when possible. Considering that, it's very strange that Arduino's byte type is unsigned.

“Byte” (in various capitalizations) was a very commonly defined type in embedded C programming LONG before wiring or processing. The various variations were one of the reasons that the int8_t and etc were added to the standard...

How about using "boolean" instead of bool?

pert:
How about using "boolean" instead of bool?

Not keen on that either.
If you're going to have "boolean", why not go the whole hog?
"integer", "character", "floating_point", "structure" etc. :smiley:

AWOL:
Not keen on that either.

Me neither. In fact, I did a big campaign to discourage the use of the boolean type:

The reason I brought up boolean is because it seemed like westfw was disagreeing with my theory that Arduino's byte type is due to emulating the Processing language. I feel that Arduino's boolean type is more evidence in favor of my theory, since I doubt that is a long established tradition in embedded C programming.

Is it a valid statement that there are no special language accommodations need to be made when designing a programming language for a 8-bit processor that has access to 2KB of RAM?

Would people condemn the idea of wringing the last bit of functionality and efficiency from these micro-controllers?

Other the the effort to add it to the library, which I am sure is substantial, what would be the disadvantages of adding a 1-bit auto bit-packed variable and a 24 bit integer variable to the standard Arduino library?

I don't condemn wringing out performance, as long as it is not at the expense of legibility and maintainability.

As has already been mentioned, the compiler already supports 24 bit integer variables, even if the Arduino libraries haven't quite caught up with this advance.

Is it a valid statement that there are no special language accommodations need to be made when designing a programming language for a 8-bit processor that has access to 2KB of RAM?

  • First, "Arduino" is not a programming language. It's more of a "framework" based on standard C/C++, and is not free to change the language. I mentioned that before.
  • C/C++ already has some single-bit capabilities (via bitfields in structures), and avr-gcc already has 24bit integer support. I mentioned that before, too. They're not called out in the Arduino documentation because they're considered "advanced" topics that would be confusing to the Arduino Target Audience of beginners (well, 24-bit integers weren't supported in the compiler version original used by Arduino.)
  • It's not like either bits or 24bit values are implemented especially efficiently on an AVR or ARM. An 8051 or PIC has a segment of bit-addressable memory, so a bunch of compilers for them added a way to support that, lest the assembly language folks be scared away, On an AVR, manipulating bits "manually" is going to be just as fast as anything the compiler could do, generally speaking.
  • And finally, I think one could make a good argument that putting "special features" in a language to cater to the limitations (or features) of a particular CPU really is a pretty HORRIBLE idea. The languages that have succeeded over the decades are the ones that haven't done so. And modern programmers curse the PIC/8051 code with its [color=maroon]PORTA.1 = 1[/color]; constructs every time they need to port it to a more modern chip, and/or a different compiler. Meanwhile, the more generic compilers have improved their capabilities and produce better code overall than the specialy-modifed compilers ever did.

These days, when space is so tight that you need to think about bit and 24bit variables, you'd be better off just getting a bigger processor. (ATmega4808: 3x the RAM and 50% more flash than an ATmega328p. And cheaper, too. Without even need to look at ARM chips.)

Or a '1284P. 16K SRAM, 128K flash, dual hardware serial ports, 32 IO total, and supportable by the IDE with this core file addition

westfw:
First, "Arduino" is not a programming language. It's more of a "framework" based on standard C/C++

I'm very interested in this topic. When I first started with Arduino I though .ino files were written in Arduino language. As I realized how awesome microcontrollers are and made the decision to dive deeper into this world, I started looking at alternatives to Arduino. I felt that learning a proprietary "toy" language would be a waste of my time in the long run, as I reached the limits of what I could do with the language and decided to move on. Then I read that the Arduino language was C++. That was a big "aha!" moment for me, which made me confident that sticking with Arduino was the right decision.

When I've seen people talk about the Arduino language, it's usually done by beginners or people denigrating the Arduino project. I was aware that somewhere on the Arduino site they talk about the Arduino language, but I thought of that as perhaps just an attempt to make things seem less intimidating to a beginner who might just shut down at mention of C++. My belief was further reinforced by a Hackaday article from Elliot Williams, who always writes excellent articles:

Over the years, I've corrected people talking about the Arduino language here several times. I've thought that the impression that there is an Arduino language and an "Arduino compiler" was harmful to the learning process and led to misconceptions (perhaps like this discussion).

Recently, I submitted a proposal to Arduino about adding some text about C++ to the Arduino Language Reference pages. I was informed by a couple of very knowledgeable Arduino employees, whose opinions I respect, that .ino files are written in Arduino language, not C++:

I understand the sketch preprocessing process, but I never thought that it made enough of a difference to qualify the code written in .ino files as a new programming language. This made me realize that I have no clue where the line is on what becomes a new programming language. Although I've seen well thought out arguments about why there is no Arduino language, I've never seen one arguing the contrary. It would be interesting to see something like that written by someone knowledgeable on the subject of programming languages.

I don't think of it as a new language, more as a pidgin or creole - it isn't exactly C++, but one should just about be able to make oneself understood to a native speaker.
(Among the Koorie people from the Victoria outback in Australia, a solar eclipse is "Kerosene lamp b'long Jesus gone bugger-up". source: The Telegraph)

I don't think it qualifies as a dialect.

The libraries that allow Arduino to cross-compile and load the code are quite and achievement. Dozens of boards use the Arduino's IDE. Because Arduino's language is unique, it is language. It may mostly be C, but that's not all it is.

My purpose in asking for the data types is not only for efficiency, but for readability. It could be said that manual bit packing is clever, but its code is ugly, and distracting from the larger program. A compiler could easily pack, in this case, 8 bits into a byte.

The problem comes with code trans-portability and readability when moving to a processor with a larger word length. If there was an auto-bitpacked variable, the same code would just be more memory efficient because the library/compiler would know the word length.

If 1-bit auto-bit packed variables as well as 24-bit integers were integrated into Arduino's...vocabulary--would you avoid using them, or would you use them?

BrendaEM:
Because Arduino's language is unique, it is language.

I wrote a library with some unique functions and typedefs. Did I create a new programming language?

BrendaEM:
It may mostly be C

There's more C++ than C.

BrendaEM:
If 1-bit auto-bit packed variables as well as 24-bit integers were integrated into Arduino's...vocabulary--would you avoid using them, or would you use them?

First of all, it's already been explained to you that we have 24 bit variables. Use them if you like. Case closed on that.

As for 1 bit variables, please provide a demonstration of how this should be implemented in Arduino's core library. Remember that we are using a standard C++ compiler. Arduino is not in the business of writing compilers (nor would you want them to be).

"bool" or "boolean" could be a single bit, except for C's desire to have basic types be pointable-to (and probably promotion issues, too.) Then it would just work the same way that "bool" works now.
I'm not sure which Arduino library functions would actually need to behave differently for single-bit values, or which ones would benefit from being able to (what good is having a 1-bit variable if it takes a full register to pass to subroutines, and/or extra instructions to extract from RAM/etc?)

It's sort of a shame that none of the big-name compiler/;anguage gurus jumped on ARM's "bit-banding" feature as a way to provide full-featured 1-bit types. (It seems it's been dropped from the ARM due to lack of interest.) OTOH, the lack of 1-bit variables in any standard computer language that I know of probably means that it has seven more "problems" than the ones I've mentioned.