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