Vary size of char from 1 to 2

What is it you are actually trying to achieve here?

In C, sizeof(char) is always 1 (by definition), and it is always the smallest size the target can directly access. Since the ARM can directly access 8-bit bytes, that is the size of a char. The most that you can do with most compilers is chose whether the default is signed or unsigned, although if your code depends on that setting, your code is badly written.

Trying to write C on architectures with chars greater than 8-bit is a PITA. It's not something one would chose voluntarily.

No way. If you're very lucky, you may manage to change the number of bytes occupied by a char, but you cannot ever possibly be allowed to change the size of it. If you managed to get sizeof(char)!=1, that beast you created would no longer be a C compiler.

Anyway: what on earth do you hope to achieve by this?

Not always. It's the smallest size the target can address that is larger than 7 bits. Or something like that. On a machine that can directly address 1 bit, a char is not allowed to be 1 bit.

It's not that bad. You've got to pay attention to what you're doing, but no more so than is normally required in an usafe language like C.

Writing C is not something one would choose voluntarily. ;)

Are you trying to use Unicode characters ?

At least in C99 this might be possible using if it contains sensible definitions.

Paul

On 10 Jan 2006 16:38:03 +0100, David Brown wrote in comp.arch.embedded:

Not that bad, you just have to be careful.

I've been doing it on a TI motor control DSP for quite some time now. Char, short, and int are all 16 bits, long is 32. Did some work in the past on an Analog Devices 32-bit DSP where char, short, int, and long were all 32 bits.

I am using M68AW512M RAM.It has 2 pins to read/write the upper or lower byte. When i try to write a lower byte(char) onto this by enabling the lower byte pin, it writes that to both lower as well as higher byte and vice-versa. When i try to write a single word, it writes it correctly on both the lower and upper bytes. Problem is only when i try writing a byte or in other words a ' char '. That is why, i was trying to change the size of char from a byte to 2 bytes.

Can you suggest me some other way to overcome this problem. Thanks RahulS

I am using M68AW512M RAM.It has 2 pins to read/write the upper or lower byte. When i try to write a lower byte(char) onto this by enabling the lower byte pin, it writes that to both lower as well as higher byte and vice-versa. When i try to write a single word, it writes it correctly on both the lower and upper bytes. Problem is only when i try writing a byte or in other words a ' char '. That is why, i was trying to change the size of char from a byte to 2 bytes.

Can you suggest me some other way to overcome this problem. Thanks RahulS

I am using M68AW512M RAM.It has 2 pins to read/write the upper or lower byte. When i try to write a lower byte(char) onto this by enabling the lower byte pin, it writes that to both lower as well as higher byte and vice-versa. When i try to write a single word, it writes it correctly on both the lower and upper bytes. Problem is only when i try writing a byte or in other words a ' char '. That is why, i was trying to change the size of char from a byte to 2 bytes.

Can you suggest me some other way to overcome this problem. Thanks RahulS

Yes, that's true - a char must be at least 8 bits. But as sizeof(char) is always 1, and all other types are defined as multiples of char, C itself is unable to directly address anything smaller even if the target architecture supports it. Unless, of course, your compiler has non-standard extensions...

It's an extra thing to keep in mind. For many tasks, it makes little difference, but when trying to manipulate character-based telegrams using the least possible ram space it is very much in the way. It certainly leads to unportable code (you don't want code filled with byte extraction functions if you don't need it!).

If you *must* use google groups, please learn to use it properly so that context is included in your replies.

As for your problem, it's a hardware issue, and depends greatly on the particular microcontroller connected to the RAM. Microcontrollers which directly access 16-bit (or greater) buses always have some sort of byte select or byte mask pins that are used for precisely this purpose - they are used to direct the ram to only store in the correct bytes.

Your hardware is broken.

I suggest you fix your hardware.

It would be easier if the pre-processor knew the sizes of types. That way the byte-extraction code could be automagically included or not. Since that's not the case, using macros that are conditional on the target architecture works pretty well.

Nonsense. Of course it knows! is guaranteed to be available in every C compiler rightfully bearing that name, and it contains all the information needed in a form the preprocessor can access. For starters, all you need is a single

#include

#if CHAR_BIT > 8 # error Arghhh! #endif

in the right place if the source.

You're right. I forgot about that. [However, this being. c.a.e, a lot of people are stuck using C compilers not rightfully bearing that name.]

Yes, theoretically you can use this sort of pre-processor stuff to write "portable" code that takes into account the width of a char. But you cannot write good, clean, legible code (for things like character-based messages) that compiles efficiently and works well on 8-bit char and

Having said that, I've written programs on 16-bit char targets, and they work. It's just another inconvenience to deal with.