Internal representation

[LGR]

How are integers, bytes and bits stored in RAM; packed, or using a full 32-bit word?

Also, it seems strange to me that you carried over the terminology from the PIC24, and call 16-bit "word", and 32-bit "dword". Shouldn't "word" be 32 bit, and 64 be "long"?

[srdjan]

How are integers, bytes and bits stored in RAM; packed, or using a full 32-bit word?

Also, it seems strange to me that you carried over the terminology from the PIC24, and call 16-bit "word", and 32-bit "dword". Shouldn't "word" be 32 bit, and 64 be "long"?

- In such case, I guess that byte would be 16bit and how should we call 8bits then?
Either way around we are missing a type name

Usually, integer type is bounded to a platform basic type determined by a memory organization (32bit here).
All other types are specific to compiler implementation.
For example, in win32 Delphi, integer is 32bits, but word type is 16bits.

We decided to keep backward compatibility and enable users to easily port their existing codes and migrate to pic32 in a sec... or two

[LGR]

I'm an old guy who remembers 32-bit mainframes. The convention there was "word" was 32, and "byte" was 8. The hardware supported both word and byte addressing. There were no 16-bit types. With a 32 bit word, it's hard to imagine a use for them.

But you didn't answer the first question. Just to be perfectly clear, does a byte use an entire 32 bit word, or does the code pack 4 of them into a word? Same question for bits. If they're not packed, I can't see any legitimate use for 16-bit types.

[srdjan]

Hi,

I'm an old guy who remembers 32-bit mainframes. The convention there was "word" was 32, and "byte" was 8. The hardware supported both word and byte addressing. There were no 16-bit types. With a 32 bit word, it's hard to imagine a use for them.

But you didn't answer the first question. Just to be perfectly clear, does a byte use an entire 32 bit word, or does the code pack 4 of them into a word? Same question for bits. If they're not packed, I can't see any legitimate use for 16-bit types.

Sorry, I have missed the first one.
Variables are packed with regards to their alignment.
8bits can be placed anywhere (alignment 1).
16bits must be placed at even addresses (alignment 2).
32 and 64bits must be placed at addresses divisible by 4 (alignment 4).

So using 8bits or 16bits instead of 32bits consumes less memory with same code efficiency.

P.S. Architecture itself does support placing any size at any address (i.e. 32bits at odd addresses), but code for accessing is highly inefficient.

[LGR]

It looks like I'm going to have to read the Microchip literature more thoroughly.

Thanks.

[p.erasmus]

8bits can be placed anywhere (alignment 1).
16bits must be placed at even addresses (alignment 2).
32 and 64bits must be placed at addresses divisible by 4 (alignment 4).

So using 8bits or 16bits instead of 32bits consumes less memory with same code efficiency.

P.S. Architecture itself does support placing any size at any address (i.e. 32bits at odd addresses), but code for accessing is highly inefficient

This should be done by the compiler if I am not mistaken or should we as the user take care of this

Regards

[rajkovic]

8bits can be placed anywhere (alignment 1).
16bits must be placed at even addresses (alignment 2).
32 and 64bits must be placed at addresses divisible by 4 (alignment 4).

So using 8bits or 16bits instead of 32bits consumes less memory with same code efficiency.

P.S. Architecture itself does support placing any size at any address (i.e. 32bits at odd addresses), but code for accessing is highly inefficient

This should be done by the compiler if I am not mistaken or should we as the user take care of this

Regards

Yes compiler is taking care about alignment and packing variables at right address .