Reply by glen herrmannsfeldt●December 21, 20032003-12-21
Randy Yates wrote:
(snip)
> As far as I know, the C standard never did require a
> "char" to be 1 byte. To assume such
> a thing is a fairly serious error in the interpretation
> of the operation of the C language.
> Thus their "primary disadvantage" is no disadvantage whatsoever.
C does require char to be one byte, but that byte doesn't
have to have 8 bits. It has to have at least 8 bits.
-- glen
Reply by Jerry Avins●December 20, 20032003-12-20
Randy Yates wrote:
...
> As far as I know, the C standard never did require a "char" to be 1
> byte. ...
ANSI C defines a byte as the larger of
� the number of bits needed to contain a system character
� the smallest addressable storage element
� eight bits.
When an architecture allows octet-addressable storage and the C
implementation uses eight-bit characters, a C byte is eight bits. By
definition in C, sizeof(char) is always 1, even if, as on a 'C30, it is
32 bits. To avoid C's dilution of the meaning of "byte", use "octet".
Jerry
--
Engineering is the art of making what you want from things you can get.
�����������������������������������������������������������������������
Reply by Jerry Avins●December 20, 20032003-12-20
Randy Yates wrote:
> Bawr wrote:
>
>> Here is a document that addresses the pbm.
>> http://focus.ti.com/lit/an/spra757/spra757.pdf
>
>
> It is interesting to note the following statement in
> this reference:
>
> The alternative option, which is not implemented in the RTS library,
> is to split each target char
> into multiple host bytes (when writing from target to host), and pack
> multiple host bytes into each
> target char (when reading from host to target). This has the advantage
> that the data is preserved
> intact without truncation. This advantage is evident for programs that
> run only on the target and
> need to read data files written by other programs that run only on the
> target. In the example
> above, the result file would contain the 4 bytes (0xAA, 0xBB, 0xCC,
> 0xDD).
>
> *The primary disadvantage of this approach is that the number of bytes
> in the file does not equal
> the number of chars written.*
>
> As far as I know, the C standard never did require a "char" to be 1
> byte. To assume such
> a thing is a fairly serious error in the interpretation of the operation
> of the C
> language. Thus their "primary disadvantage" is no disadvantage whatsoever.
--
Engineering is the art of making what you want from things you can get.
�����������������������������������������������������������������������
It is interesting to note the following statement in
this reference:
The alternative option, which is not implemented in the RTS library, is to split each target char
into multiple host bytes (when writing from target to host), and pack multiple host bytes into each
target char (when reading from host to target). This has the advantage that the data is preserved
intact without truncation. This advantage is evident for programs that run only on the target and
need to read data files written by other programs that run only on the target. In the example
above, the result file would contain the 4 bytes (0xAA, 0xBB, 0xCC, 0xDD).
*The primary disadvantage of this approach is that the number of bytes in the file does not equal
the number of chars written.*
As far as I know, the C standard never did require a "char" to be 1 byte. To assume such
a thing is a fairly serious error in the interpretation of the operation of the C
language. Thus their "primary disadvantage" is no disadvantage whatsoever.
--
% Randy Yates % "...the answer lies within your soul
%% Fuquay-Varina, NC % 'cause no one knows which side
%%% 919-577-9882 % the coin will fall."
%%%% <yates@ieee.org> % 'Big Wheels', *Out of the Blue*, ELO
http://home.earthlink.net/~yatescr
Reply by Randy Yates●December 19, 20032003-12-19
Raymond Toy wrote:
>>>>>>"Bawr" == Bawr <lba@step.polymtl.ca> writes:
>
>
> Bawr> Hi,
> Bawr> I found that file IO routines (fread and fwrite) don't work properly on
> Bawr> CCS 2.12 on the C55x platform. It seems to be reading and writing byte by
> Bawr> byte even if you specify the right size.
> Bawr> Has anybody else run into the same pbm? If so, is there any patch to get
> Bawr> around this quickly?
>
> Yes, I've run into that problem. I don't know of any patch. I just
> gave up and used probe points. Which was actually good because probe
> points run MUCH faster because the DSP isn't running fread/fwrite
> code.
I have not noticed a difference, and it sure is convenient to be able
to load the code and run without having to pull up several menus and fill
out parameters (yes, you could write a gel file, but that's work too),
especially when you have to restart CCS often.
--
% Randy Yates % "...the answer lies within your soul
%% Fuquay-Varina, NC % 'cause no one knows which side
%%% 919-577-9882 % the coin will fall."
%%%% <yates@ieee.org> % 'Big Wheels', *Out of the Blue*, ELO
http://home.earthlink.net/~yatescr
> Hi,
> I found that file IO routines (fread and fwrite) don't work properly
on
> CCS 2.12 on the C55x platform. It seems to be reading and writing byte by
> byte even if you specify the right size.
> Has anybody else run into the same pbm? If so, is there any patch to get
> around this quickly?
> TIA.
> LB
>
>
Reply by Bawr●December 16, 20032003-12-16
I agree, it runs much FASTER with probe points but I'd like to keep my code
portable as much as possible. I am running the same C code on different
platforms at the same time. Using probe points will make my code platform
depend. I am running out of time to write a fix. There must be a patch
somewhere unless TI really wants us to use those probe points but I see no
reason why
ThanX 4 u help.
LB
"Raymond Toy" <toy@rtp.ericsson.se> wrote in message
news:4nznds4j7t.fsf@edgedsp4.rtp.ericsson.se...
> >>>>> "Bawr" == Bawr <lba@step.polymtl.ca> writes:
>
> Bawr> Hi,
> Bawr> I found that file IO routines (fread and fwrite) don't work
properly on
> Bawr> CCS 2.12 on the C55x platform. It seems to be reading and
writing byte by
> Bawr> byte even if you specify the right size.
> Bawr> Has anybody else run into the same pbm? If so, is there any
patch to get
> Bawr> around this quickly?
>
> Yes, I've run into that problem. I don't know of any patch. I just
> gave up and used probe points. Which was actually good because probe
> points run MUCH faster because the DSP isn't running fread/fwrite
> code.
>
> Ray
Bawr> Hi,
Bawr> I found that file IO routines (fread and fwrite) don't work properly on
Bawr> CCS 2.12 on the C55x platform. It seems to be reading and writing byte by
Bawr> byte even if you specify the right size.
Bawr> Has anybody else run into the same pbm? If so, is there any patch to get
Bawr> around this quickly?
Yes, I've run into that problem. I don't know of any patch. I just
gave up and used probe points. Which was actually good because probe
points run MUCH faster because the DSP isn't running fread/fwrite
code.
Ray
Reply by Bawr●December 16, 20032003-12-16
Hi,
I found that file IO routines (fread and fwrite) don't work properly on
CCS 2.12 on the C55x platform. It seems to be reading and writing byte by
byte even if you specify the right size.
Has anybody else run into the same pbm? If so, is there any patch to get
around this quickly?
TIA.
LB