> Grant Edwards <grante@visi.com> wrote:
>
>> 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,
>
> Nonsense. Of course it knows! <limits.h> 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 <limits.h>
>
> #if CHAR_BIT > 8
> # error Arghhh!
> #endif
>
> in the right place if the source.
>
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
16-bit char (and 32-bit char) architectures. limits.h and
pre-processing directives can give you efficient code, or legible code,
but not both.
Having said that, I've written programs on 16-bit char targets, and they
work. It's just another inconvenience to deal with.
Reply by Grant Edwards●January 11, 20062006-01-11
On 2006-01-11, Hans-Bernhard Broeker <broeker@physik.rwth-aachen.de> wrote:
> Grant Edwards <grante@visi.com> wrote:
>
>> 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,
>
> Nonsense. Of course it knows! <limits.h> is guaranteed to be
> available in every C compiler rightfully bearing that name,
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.]
--
Grant Edwards grante Yow! I always liked FLAG
at DAY!!
visi.com
Reply by Hans-Bernhard Broeker●January 11, 20062006-01-11
Grant Edwards <grante@visi.com> wrote:
> 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,
Nonsense. Of course it knows! <limits.h> 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 <limits.h>
#if CHAR_BIT > 8
# error Arghhh!
#endif
in the right place if the source.
--
Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.
Reply by Grant Edwards●January 11, 20062006-01-11
On 2006-01-11, David Brown <david@westcontrol.removethisbit.com> wrote:
> 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!).
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.
>>> It's not something one would chose voluntarily.
>>
>> Writing C is not something one would choose voluntarily. ;)
--
Grant Edwards grante Yow! Look!! Karl Malden!
at
visi.com
Reply by Grant Edwards●January 11, 20062006-01-11
On 2006-01-11, RahulS <rahuls@kpitcummins.com> wrote:
> 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.
Your hardware is broken.
> 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.
I suggest you fix your hardware.
--
Grant Edwards grante Yow! I love FRUIT
at PICKERS!!
visi.com
Reply by David Brown●January 11, 20062006-01-11
RahulS wrote:
> 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
>
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.
Reply by David Brown●January 11, 20062006-01-11
Grant Edwards wrote:
> On 2006-01-10, David Brown <david@westcontrol.removethisbit.com> wrote:
>
>> In C, sizeof(char) is always 1 (by definition), and it is
>> always the smallest size the target can directly access.
>
> 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.
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...
>
>> 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 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.
>
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!).
>> It's not something one would chose voluntarily.
>
> Writing C is not something one would choose voluntarily. ;)
>
Reply by RahulS●January 11, 20062006-01-11
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
Reply by RahulS●January 11, 20062006-01-11
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
Reply by RahulS●January 11, 20062006-01-11
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