For the ARM9 AT91SAM9261 can I safely say that a "word" is 32-bits?
Thanks. :)
-Henk
For the ARM9 AT91SAM9261 can I safely say that a "word" is 32-bits?
Thanks. :)
-Henk
Not really. The compiler makes that choice.
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:
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
(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 http://www.wescottdesign.com Posting from Google? See http://cfaj.freeshell.org/google/ "Applied Control Theory for Embedded Systems" came out in April. See details at http://www.wescottdesign.com/actfes/actfes.html
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
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
The C99 says the following:
VLV
I've never seen a C99 compliant embedded compiler - and even so I don't think this statement is true.
Regards, Richard.
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
A conforming implementation shall define CHAR_BIT macro, not CHAR_BITS.
-- Unicals Group -- Embedded C++ for Your IP Cores http://www.unicals.com
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
VLV
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.
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
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.
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 & visi.com COSTELLO here on suspicion of HIGHWAY ROBBERY!!
Thanks. I figured I didn't have it exactly right.
-- Tim Wescott Wescott Design Services http://www.wescottdesign.com Posting from Google? See http://cfaj.freeshell.org/google/ "Applied Control Theory for Embedded Systems" came out in April. See details at http://www.wescottdesign.com/actfes/actfes.html
To summarize ... you guys are in complete agreement? :-)
-- Michael N. Moran (h) 770 516 7918 5009 Old Field Ct. (c) 678 521 5460 Kennesaw, GA, USA 30144 http://mnmoran.org "So often times it happens, that we live our lives in chains and we never even know we have the key." The Eagles, "Already Gone" The Beatles were wrong: 1 & 1 & 1 is 1
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 FAQs for comp.lang.c http://c-faq.com/ comp.lang.c++ http://www.parashift.com/c++-faq-lite/alt.comp.lang.learn.c-c++ http://www.contrib.andrew.cmu.edu/~ajo/docs/FAQ-acllc.html
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 visi.com RUBIK's CUBE HANDBOOK FOR DEAD CAT LOVERS"...
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.