sizeof(int) ?

Created Fri, 27 May 2011 23:15:18 +0000 by WestfW

WestfW

Fri, 27 May 2011 23:15:18 +0000

It looks like the pic32 compiler defaults to 32-bit ints (which is typical of MIPS.)

Any ideas for noticing and avoiding the issues that this would cause (aside from using int16_t everywhere instead, which is probably correct, but unlikely to please the arduino crowd)? I'm not even sure what problems this WOULD cause (more problems going the other direction.) Can you #define int int8_t somewhere are expect reasonable behavior?

Mark

Sat, 28 May 2011 14:11:26 +0000

West

The size of variables on Arduino has been something I have been paying attention to for some time. Here is the complete breakdown on the PIC32

CPU Type = 32MX795F512L size of char = 1 size of short = 2 size of int = 4 size of long = 4 size of ull = 8 size of float = 4 size of double= 4 size of void* = 4

I really dont think its a problem unless one place a variable is declared int16_t and another place its declared int and the place and were its declared as int exceeds 16 bit size. For the most part, the compiler takes care of it.

All of the int8_t, uint8_t, etc are defined in one of the .h files

Mark

WestfW

Sat, 28 May 2011 19:54:47 +0000

It seems like the biggest problems would happen in the other direction. Code that works fine on a PIC32 would fail to work (overflows of 16 bits) when run on an AVR.

The most dangerous issue is probably with C's "intermediate results are ints" rule, which I see people running into relatively often on the arduino forums, and wouldn't be affected by most (any?) user-added behaviors or definitions...

jasonk

Tue, 14 Jun 2011 16:45:44 +0000

Keep in mind that the native 32-bit int size on PIC32 will give the best performance and code size.

Jacob Christ

Sun, 19 Jun 2011 00:23:30 +0000

It seems like the biggest problems would happen in the other direction. Code that works fine on a PIC32 would fail to work (overflows of 16 bits) when run on an AVR.

Not so my friend... Already having issues with structures that are suppose to be a certain size for the chip I'm trying to talk to and they have grown and now bytes don't line up...

Jacob

KM6VV

Sun, 19 Jun 2011 02:14:25 +0000

Do you know about #pragma pack for arrays?

Alan KM6VV

Jacob Christ

Sun, 19 Jun 2011 15:39:41 +0000

Do you know about #pragma pack for arrays?

I do not, please elaborate.

Jacob

Jacob Christ

Sun, 19 Jun 2011 20:19:57 +0000

size of ull = 8

I'm having trouble finding any documentation on this type. Is is signed or unsigned? My guess is this stands for unsigned long long, if so, is there a signed version?

Jacob

KM6VV

Sun, 19 Jun 2011 20:41:40 +0000

A quick google brings up this:

http://gcc.gnu.org/onlinedocs/gcc/Structure_002dPacking-Pragmas.html

*For compatibility with Microsoft Windows compilers, GCC supports a set of #pragma directives which change the maximum alignment of members of structures (other than zero-width bitfields), unions, and classes subsequently defined. The n value below always is required to be a small power of two and specifies the new alignment in bytes.

#pragma pack(n) simply sets the new alignment.
#pragma pack() sets the alignment to the one that was in effect when compilation started (see also command-line option 

Basically, it allows one to set a tight alignment that is more easily matched to other programs' use.

Alan KM6VV

Jacob Christ

Mon, 20 Jun 2011 02:32:12 +0000

Talking to Oleg from Circuits@Home the following question came up which I didn't know the answer to and its related to this thread...

Will PIC32 compiler understand stdint.h types (like uint8_t, int16_t, etc.)?

Jacob

WestfW

Mon, 20 Jun 2011 07:16:26 +0000

Will PIC32 compiler understand stdint.h types (like uint8_t, int16_t, etc.)?

It had better (and it seems to. Certainly the MIPS gcc has long supported those types.) Those are pretty standard, these days.

#pragma pack (or whatever) will prevent

struct {
   char foo;
   long bar;
} s;

From being 8 bytes long instead of just 5, but it won't magically prevent:

struct {
  int foo;
  int bar;
} s;

from being 8 bytes on a PIC32 and only 4 bytes on an AVR. (never use types without explicit sizes on any structure that you plan on mapping to a real-world piece of data.)

svofski

Tue, 05 Jul 2011 12:47:16 +0000

It had better (and it seems to. Certainly the MIPS gcc has long supported those types.) Those are pretty standard, these days.

It's not the compiler, they are defined in headers. To use them just

#include <inttypes.h>