VxWorks sizeof(int) question.
Tom Miller
I'm here to ask a remedial question. A bit embarassing, but here goes:
What determines the size of an "int" in any given vxworks system? I am
running a vxworks version based on the '486 bsp, and the other day when i
was having a problem I typed "sizeof(int)" in the command shell and got 4 as
a result - my system considers an int to be 32 bits!
Is it the architecture of the target processor that determines the size of
an int? Is it the operating system? Is this a settable parameter somewhere
in VxWorks?
any explanation would be appreciated.
Tom Miller
Motion Engineering Inc.
Ps Thanks to Andreas Wolf and Bob Anderson for responding to my first query.
Mark Fischer
the vxWorks Users Group Exploder wrote:
> Is it the architecture of the target processor that determines the size of
> an int? Is it the operating system? Is this a settable parameter somewhere
> in VxWorks?
>
According to the original K&R spec, the size of "int" is completely at
the mercy of the compiler writer, but is typically the most efficient
transfer size for the processor being used. That's why it is a mortal
sin against God and Man to assume the size of "int". On Crays, for
example, "int" is a 64 bit word.
Hope that helps,
Mark
~~~~
Chris Hann
the vxWorks Users Group Exploder wrote:
>
> Submitted-by vxwexp...@csg.lbl.gov Wed May 10 14:27:06 2000
> Submitted-by: Tom Miller <To...@motioneng.com>
>
> Hello everyone,
>
> I'm here to ask a remedial question. A bit embarassing, but here goes:
>
> What determines the size of an "int" in any given vxworks system? I am
> running a vxworks version based on the '486 bsp, and the other day when i
> was having a problem I typed "sizeof(int)" in the command shell and got 4 as
> a result - my system considers an int to be 32 bits!
>
> Is it the architecture of the target processor that determines the size of
> an int? Is it the operating system? Is this a settable parameter somewhere
> in VxWorks?
>
> any explanation would be appreciated.
>
> Tom Miller
> Motion Engineering Inc.
>
> Ps Thanks to Andreas Wolf and Bob Anderson for responding to my first query.
>
An int is intended to be the native integer data size for the processor, on
32bit processors like the 486 this would give a 32 bit int, you would expect a
16 bit processor to have a 16 bit int and so on.
Chris
Fred Roeber
> What determines the size of an "int" in any given vxworks system? I am
> running a vxworks version based on the '486 bsp, and the other day when i
> was having a problem I typed "sizeof(int)" in the command shell and got 4 as
> a result - my system considers an int to be 32 bits!
In my experience, the size of an int is solely a compiler issue but is
normally tied to the processor architecture. I have seen cases where ints
are 16, 32, or 64 bits. With TI C40 DSPs, you even have the odd case
where ints are 32 bits but sizeof(int) = 1. All I'm trying to get at is
that if you are writing portable software, you shouldn't count on an int
being a certain size and certainly shouldn't count on being able to store
a pointer value in an int.
Some compilers I have worked with in the past have even provided
compiler switches that let you adjust the size of any integer. As far
as I know, the GNU C compilers don't provide such an option but I could
be wrong. Fred
| Fred J Roeber, BBN Systems & Technologies |
| 4 John Clarke Road Middletown, RI 02842-5202 |
| fro...@bbn.com 401-848-3548 |
| Division Scientist, High Performance Computing |
Michael Lawnick
> On Wed, 10 May 2000, Tom Miller <To...@motioneng.com> wrote:
>
> > What determines the size of an "int" in any given vxworks system? I am
> > running a vxworks version based on the '486 bsp, and the other day when i
> > was having a problem I typed "sizeof(int)" in the command shell and got 4 as
> > a result - my system considers an int to be 32 bits!
>
The size of an int is the number of char you need to store ->
If your machine is a DSP, it mostly uses 32 bit characters and you
will get sizeof(int) is 1 or 2.
In DOS, where a charcter is a byte and the processor is 16 bit,
sizeof(int) is 2, whereas on a PPC (32bit) its 4.
Because of this problems, vxWorks defines the types
UINT8, UINT16 and UINT32 / INT8, INT16, INT32.
They are defind in BSP to guarantee an architecture independant
coding.
HTH
MfG
Lawnick, SOFTEC GmbH
==============================================
SOFTEC GmbH Tel +49-731-96600-0
Promenade 17 Fax +49-731-96600-23
D-89073 Ulm Michael Lawnick
Germany law...@softec.de
==============================================
David Laight
> my system considers an int to be 32 bits!
What did you expect? As stated by others int is (usually) the 'natural size' of
integers on the system. Definitely 32 bits on a 486.
Unix systems (and probably everything except some ms o/s) have used 32 bit
integers for all 68xxx and 386 systems. I think the last common 16 bit int Unix
were for the 286 and pdp11.
vxWorks definitely requires sizeof (int) == sizeof (long) == sizeof (ptr).
(and code pointers to be the same size as data pointers.)
Whether an 'int' is 16, 32 or 64 (or 8, 24, 36, 48 or...) bits is not strictly a
compiler issue, but an ABI (Application Binary Interface) one. Different parts
of a system (compiled at different times) have to agree on the sizes of data
items.
The move to 64 bit systems causes its own problems. Two common sets of data
sizes are used ILP64 (int, long and pointer are 64bit) and LP64 (32 bit int, 64
bit long and pointer). DEC use ILP64, Solaris LP64.
Sun have had to go through all the structures that user processes might pass
into the kernel and change them to use fixed size types - so the same kernel can
support 32 bit and 64 bit applications.
The 64 bit DEC (now COMPAQ) systems are not binary compatible with any 32 bit
system.
The C standards body is about to (and has been for a few years) define some
fixed size integer types. These will be in int_types.h (I think). The current
solaris loads have a sys/int_types.h that contains what they think the standard
will be.
int8_t an 8 bit signed integer
int16_t a 16 bit signed integer
int32_t a 32 bit signed integer
int64_t a 64 bit signed integer (if supported)
uint8_t an 8 bit unsigned integer
uint16_t a 16 bit unsigned integer
uint32_t a 32 bit unsigned integer
uint64_t a 64 bit unsigned integer (if supported)
intptr_t a signed integer which can hold any data pointer
uintptr_t an unsigned integer which can hold any data pointer
The names of the other types in my header file are probably wrong!
If you are writing code that needs specific sized integers (eg to map onto
hardware registers) then using the above names (or similar ones) with
appropriate system (ABI) dependant definitions will avoid confusion.
I find it usuful to define vuint8 (volatile unsigned 8 bit integer) etc.
Be aware that, just because the domian of a variable is restricted, it is not
always appropriate to use a restricted type. Code size and execution speed will
almost always be smaller if variables are defined as int instead of short or
char. Passing small integers to procedures can be particularly messy an many
implementations.
David
PS: I've no idea what you would do for a C implementation on a system that does
BCD arithmetic and has hydrid binary/decimal addressing - like the old ICL
System 25. Maybe its a good job no one makes anything like that any more.
----------------------------------------------------------------
David Laight email: d...@tadpole.co.uk
Tadpole Technology plc phone: +44 1223 428 232
Cambridge, UK fax: +44 1223 428 201
Jim Way
use the types UINT8, UINT16, etc. Especially when it is important that a
variable contain a specific maximum value or roll over at a specific value
(yes, I know it is "better" to say "if (++x > MAX) x = 0" but efficiency
sometimes wins out over good coding practices). You might also check the
limits.h file. It has some interesting constants like __LONG_MAX__ that
might be helpful. If you don't find what you're looking for, define your own
as the first code you write for your project. Also, don't be afraid to use
an assertion like ASSERT (sizeof(int)==sizeof(void*)) if you really feel the
need to stuff a pointer into a numeric variable.
Class dismissed <grin>
Jim
|
|Because of this problems, vxWorks defines the types
|UINT8, UINT16 and UINT32 / INT8, INT16, INT32.
|They are defind in BSP to guarantee an architecture independant
|coding.
|
|MfG
|Lawnick, SOFTEC GmbH
|
Bruce
Fred Roeber <fro...@bbn.com> wrote:
>In my experience, the size of an int is solely a compiler issue but is
>normally tied to the processor architecture. I have seen cases where ints
>are 16, 32, or 64 bits. With TI C40 DSPs, you even have the odd case
>where ints are 32 bits but sizeof(int) = 1. All I'm trying to get at is
>that if you are writing portable software, you shouldn't count on an int
>being a certain size and certainly shouldn't count on being able to store
>a pointer value in an int.
The TI DSP is interesting. ANSI C guarantees that a sizeof(char) == 1 and
that sizeof(char) <= sizeof(short) <= sizeof(int) <= sizeof(long). This
leads me to conclude that you must have had 32bit chars also? Either that
or a non-conforming compiler.
Stephen Walsh
addressable memory it will be 8 and if you can only address memory locations
in 32bit chunks it is 32.
The ADI SHARC DSP also has
sizeof(char)=sizeof(short)=sizeof(int)=sizeof(long)=1 (all 32bit)
Steve
Bruce wrote in message <391b8491...@news.swbell.net>...
Fred Roeber
> The TI DSP is interesting. ANSI C guarantees that a sizeof(char) == 1 and
> that sizeof(char) <= sizeof(short) <= sizeof(int) <= sizeof(long). This
> leads me to conclude that you must have had 32bit chars also? Either that
> or a non-conforming compiler.
The compiler conforms. As you surmise, char's on the TI C40 DSP are also
normally 32 bits by default such that:
sizeof(char) == sizeof(int) == 1
Just goes to show that when you are trying to write portable code, you
have to be able to handle all sorts of different architectural
issues. Fred