word size.

For the ARM9 AT91SAM9261 can I safely say that a "word" is 32-bits?

Thanks. :)

-Henk

Reply to
dutchman1234
Loading thread data ...

Not really. The compiler makes that choice.

Reply to
Neil

Neil,

I am using the IAR embedded workbench and I have the option to change between Arm (32-bit) and thumb (16-bit) for the processor mode. Right now I am running in Arm mode so I am assuming that a word is 32-bits. If I switch to thumb mode then 16-bits will be used per instruction.

Is it always the case that the instruction size will be the word size? Thanks for any info!

-Henk

Neil wrote:

Reply to
dutchman1234

While technically true that the compiler (if you are referring to C) chooses the size of int, it is encouraged to be the 'natural' size for the processor which for ARM will be 32bits. Word is a somewhat more nebulous ...um.. word.

Instruction size is not at all related.

Robert

Reply to
Robert Adsett

(top posting fixed)

What are you really trying to do, and which 'word' do you care about?

If it's the size of 'int' in C, and if the compiler is ANSI compatible you can trust that 'int' is at least 16 bits (else it wouldn't be ANSI). You can count on 'long' to be at least 32 bits, 'short' to be at least

16, and 'char' to be at least 8.

Then you'll be asked to develop code on a non-compliant compiler, and you'll be screwed.

Assuming your compiler is compliant, and assuming you're not trying to write portable code, I would suggest that you do

printf("CHAR_BITS = %d, sizeof(int) = %d\n", CHAR_BITS, sizeof(int));

This will tell you how many bits in a character (almost certainly 8 on an ARM, but not so on many DSPs), and the number of 'char's that you can fit into an integer (almost certainly 4, even in thumb mode). Do check my spelling on CHAR_BITS -- I think that's right, and your compiler _should_ support it, but the standard may be different and you may have a non-compliant compiler.

If you absolutely positively must have a 16 bit integer, no more, no less, then you can use the 'int16' construct (web search for it). There's a standard for using it, but I don't like it because if you're depending on _no more than_ 16 bits, as soon as someone hands you a native 24 bit or 32 bit machine you're screwed. Worse, if someone writes 'portable' code that depends on 'int8' being exactly eight bits it'll bomb on the (much more common) 16-bit DSP chips out there whose C compilers map int, short and char to the same underlying 16-bit word size.

--
Tim Wescott
Wescott Design Services
 Click to see the full signature
Reply to
Tim Wescott

There is a standard C99 which defines the basic types uint_8t, uint_16t and so on. You are supposed to rely on the size of those types if you want to write the portable code where the number of bits is critical.

However the freaking CCS does the following:

typedef unsigned int uint_8t;

That completely invalidates the whole idea of the portability.

Even if the CPU does not have a native 8 bit type, the C99 compliant compiler must provide a software support for it, as well as for all other machine independent types.

Vladimir Vassilevsky

DSP and Mixed Signal Design Consultant

formatting link

Reply to
Vladimir Vassilevsky

These exact-width types are all typedef names named intN_t/uintN_t.

That's not true. C99 does not require either of these types.

--
Unicals Group -- Embedded C++ for Your IP Cores
http://www.unicals.com
Reply to
Ivan A. Kosarev

The C99 says the following:

  1. The exact width types are optional.

  1. If the exact width type is defined, then it must be supported.

  2. If the type is not supported, it shall not be defined.

VLV

Reply to
Vladimir Vassilevsky

I've never seen a C99 compliant embedded compiler - and even so I don't think this statement is true.

Regards, Richard.

  • formatting link
  • formatting link
    for Cortex-M3, ARM7, ARM9, HCS12, H8S, MSP430 Microblaze, Coldfire, AVR, x86, 8051 & PIC18 * * * *
Reply to
FreeRTOS.org

There is only one C99 standard, BTW.

That's right.

I'm not sure what these po #3 These types are optional. However, if an implementation provides integer types with widths of 8, 16, 32, or 64 bits, it shall define the corresponding typedef names.

That means that a conforming implementation is free not to define the typedef name int8_t if there are no 8-bit-width integer types provided by the implementation.

--
Unicals Group -- Embedded C++ for Your IP Cores
http://www.unicals.com
Reply to
Ivan A. Kosarev

A conforming implementation shall define CHAR_BIT macro, not CHAR_BITS.

--
Unicals Group -- Embedded C++ for Your IP Cores
http://www.unicals.com
Reply to
Ivan A. Kosarev

ISO/IEC 9899:1999 Paragraph 7.18

If the implementation supports for 8,16,32 etc. bit types, then the=20 corresponding exact width types must be defined.

If the type of exact width is defined, then the compiler must support it =

as the type with the exact number of bits.

If the compiler does not support for a type with a given width, then the =

corresponding exact width type should not be defined.

eger=20

by=20

  1. For each type described herein that the implementation provides,215)=20 shall declare that typedef name and define the associated=20 macros. Conversely, for each type described herein that the=20 implementation does not provide, shall not declare that=20 typedef name nor shall it define the associated macros. An=20 implementation shall provide those types described as =91=91required=92=92= , but=20 need not provide any of the others (described as =91=91optional=92=92).

VLV

Reply to
Vladimir Vassilevsky

Nonsense.

The exact-size integer types are all optional --- if the implementation doesn't have 8-bit and 16-bit integers, C99 does _not_ require a C implementor to force them down its throat.

C99 does require more integer types than previous editions (and updates) of standard C did, but a strictly 8-bit (or 16-bit) type is not among them.

--
Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.
Reply to
Hans-Bernhard Broeker

If I am using the exact size types in my program, then the compiler is supposed either to build it correctly or to give the error message about the unsupported type, so I can take care of it myself. In this sense, the C99 program is portable.

Instead, the CCS does the definitions like: typedef unsigned int uint_8t which is completely wrong. This hides the possible problems.

VLV

Reply to
Vladimir Vassilevsky

Where does it say this in the compiler documentation?

Where does the compiler state C99 compliance?

This would seem illogical and error prone - especially if the user makes unsafe assumptions about the compiler and hardware.

Regards, Richard.

  • formatting link
  • formatting link
    for Cortex-M3, ARM7, ARM9, HCS12, H8S, MSP430 Microblaze, Coldfire, AVR, x86, 8051 & PIC18 * * * *
Reply to
FreeRTOS.org

I'm pretty sure that's allowed. uint8_t is guaranteed to be _at_least_ 8 bits wide. It's allowed to be 9, or 13, or 37 or...

--
Grant Edwards                   grante             Yow!  -- Hello,
                                  at               POLICE? I"ve got ABBOTT &
 Click to see the full signature
Reply to
Grant Edwards

Thanks. I figured I didn't have it exactly right.

--
Tim Wescott
Wescott Design Services
 Click to see the full signature
Reply to
Tim Wescott

To summarize ... you guys are in complete agreement? :-)

--
Michael N. Moran           (h) 770 516 7918
5009 Old Field Ct.         (c) 678 521 5460
 Click to see the full signature
Reply to
Michael N. Moran

On Wed, 06 Sep 2006 22:21:11 -0000, Grant Edwards wrote in comp.arch.embedded:

No, you're off base on that.

All C99 conforming compilers must define these types:

(u)int_fast#_t, with # of 8, 16, 32, 64

(u)int_least#_t, with # of 8, 16, 32, 64

But the conditions on the exact width types are:

If an implementation has exact width integer types in any of the sizes of 8, 16, 32, or 64 bits that have no padding bits, no trap representations, and use 2's complement representation for negative values in the signed version, then it must define the types

(u)int#_t

For any of these widths that the implementation does not meet all of the requirements, it is specifically not to define that exact width type at all.

For our system which uses CAN bus to communicate between one master (ARM9) and multiple slaves (TI2812 motion control DSP), I wanted to write the CAN packet formatting and parsing routines once in C, and build them with no changes at all on both platforms.

On the ARM9, plain char is unsigned and all of the exact width types are available. On the TI2812, plain char is signed, but chars and ints are both 16 bits, there are no 8-bit or 64-bit integer data types.

The ARM ADS came with a that defined the fast, least, and exact width types. I made my own for the 2812, with exact 16 and 32 bit types, and fast and least for 8, 16, and 32 bit types.

I wrote the CAN format and parse routines on the DSP first, using int_least8_t and uint_least8_t. Once it was tested and working on the DSP, one of the programmers working on the ARM9 built it with ADS, and the same code worked without modification.

--
Jack Klein
Home: http://JK-Technology.Com
 Click to see the full signature
Reply to
Jack Klein

Yup, I know. I tried to cancel the post, but I guess I was too late.

Right. Those were the ones I was thinking of.

I once had similar problems talking SPI between a 68HC11 and a TI TMS320C30. On the latter a char, int, long, float, and double were all 32 bits.

--
Grant Edwards                   grante             Yow!  Okay... I'm going
                                  at               home to write the "I HATE
 Click to see the full signature
Reply to
Grant Edwards

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.