Go Down

Topic: 1-Bit and 24-Bit Integer Variables, Please (Read 728 times) previous topic - next topic

BrendaEM

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

westfw

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.

BrendaEM

#2
Apr 27, 2019, 05:46 pm Last Edit: Apr 27, 2019, 05:54 pm by BrendaEM
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.

AWOL

Quote
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.
"Pete, it's a fool (who) looks for logic in the chambers of the human heart." Ulysses Everett McGill.
Do not send technical questions via personal messaging - they will be ignored.
I speak for myself, not Arduino.

pert

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.

Arduino already uses the Byte data type, which is non-standard, but helpful
Non-standard, yes, but it's just a typedef:
https://github.com/arduino/ArduinoCore-avr/blob/1.6.23/cores/arduino/Arduino.h#L126
Code: [Select]
typedef uint8_t byte;

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.

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.

Arduino's "Setup" functionality is non-standard, but helpful.
It's just a function called from main():
https://github.com/arduino/ArduinoCore-avr/blob/1.6.23/cores/arduino/main.cpp#L43
main() is hidden away in the core library, but really it's just standard C++.

AWOL

I was never keen on Arduino's choice of "byte" as "uint8_t" - it confuses the Java programmers.
"Pete, it's a fool (who) looks for logic in the chambers of the human heart." Ulysses Everett McGill.
Do not send technical questions via personal messaging - they will be ignored.
I speak for myself, not Arduino.

pert

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.

westfw

"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...

pert

How about using "boolean" instead of bool?

AWOL

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.  :D
"Pete, it's a fool (who) looks for logic in the chambers of the human heart." Ulysses Everett McGill.
Do not send technical questions via personal messaging - they will be ignored.
I speak for myself, not Arduino.

pert

Not keen on that either.
Me neither. In fact, I did a big campaign to discourage the use of the boolean type:
https://github.com/arduino/Arduino/issues/6657

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.

BrendaEM

#11
May 08, 2019, 08:35 pm Last Edit: May 08, 2019, 08:37 pm by BrendaEM
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?

AWOL

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.
"Pete, it's a fool (who) looks for logic in the chambers of the human heart." Ulysses Everett McGill.
Do not send technical questions via personal messaging - they will be ignored.
I speak for myself, not Arduino.

westfw

Quote
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 PORTA.1 = 1; 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.)

CrossRoads

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

https://github.com/MCUdude/MCUdude_corefiles
Designing & building electrical circuits for over 25 years.  Screw Shield for Mega/Due/Uno,  Bobuino with ATMega1284P, & other '328P & '1284P creations & offerings at  my website.

Go Up