Maximum possible size of `T`

I haven't used this target, but its spec only gives it 16-bit pointers and usize:

Oops! :confounded: It's been more than 15 years since I last coded for the MSP430. Obviously I misremembered its maximum memory configuration.

Base-level MSP430 is purely 16-bit. It is MSP430X that has address bus expanded to 20 bit. Citing SLAU391F document:

The MSP430X CPU incorporates features specifically designed for modern programming techniques, such as calculated branching, table processing, and the use of high-level languages such as C. The MSP430X CPU can address a 1MB address range without paging. The MSP430X CPU is completely backward compatible with the MSP430 CPU.
The MSP430X CPU features include:
• RISC architecture
• Orthogonal architecture
• Full register access including program counter (PC), status register (SR), and stack pointer (SP)
• Single-cycle register operations
• Large register file reduces fetches to memory.
• 20-bit address bus allows direct access and branching throughout the entire memory range without
• 16-bit data bus allows direct manipulation of word-wide arguments.
• Constant generator provides the six most often used immediate values and reduces code size.
• Direct memory-to-memory transfers without intermediate register holding
• Byte, word, and 20-bit address-word addressing

I'm sorta up-to-date on the topic, because my MSP430FR5994 dev kit came yesterday (this one is MSP430X CPU) and I'm dedicating this weekend to Rustify the board (so far I've harassed it with some basic LED-blinking "hello world" in C).
If I succeed, I'll post a complete guide & working example on my GitHub account, basing on Kubuntu 20.04 toolchain.


Note that even with a formal specification this could still be "implementation defined". You see that a lot in the C and C++ specs.


If arrays (and structs in general) can never be larger than isize::MAX, then why index by usize and not isize?

Because the index can't be negative either. It doesn't make any sense to have negative indexes, while arrays never being bigger than isize::MAX is just an arbitrary rule. Also using isize would still make it possible to represent indexes that would require the array to be bigger than isize::MAX if the element size is bigger than 1 byte. On top of that is easier and quicker to detect an invalid index when using usize (just a bound check) than to detect an invalid index when using isize (a bound check and check for index>=0)


Technically, the index can be larger than isize::MAX with zero-size types, like [(); usize::MAX]. Whether that's useful is another question...


I suspect that the authors of LLVM chose to use the isize type for indices so that errors when computing an index would be more apparent. If those computations were done in usize then there would be many cases where an index value was close to usize::MAX due to wrapping when the index computation, when considered as an unbounded Integer, resulted in an erroneously-negative value.

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.