porting issues ?
navin_2016
Can somone please describe the problems one would face when we try
to port a software written in C to another platform some of them being
endianness ,alignment,data types etc ?
It would be very helpful if you could state the solution along with
problem .Also can you please give me some pointers and links to
documents so that porting can be easily accomplished ?
Navin
-
Robert Stankowic
"navin_2016" <navin...@yahoo.co.in> schrieb im Newsbeitrag
news:268bf130.03120...@posting.google.com...
> Hi,
> Can somone please describe the problems one would face when we try
> to port a software written in C to another platform some of them being
> endianness ,alignment,data types etc ?
There should be no problem as long as you strictly adhere to the C standard
(which is seldom possible).
If you put nonstandard stuff into separate compilation units, porting will
at least be easier than if you mix standard and nonstandard things
everywhere.
CBFalconer
>
> Can somone please describe the problems one would face when we
> try to port a software written in C to another platform some of
> them being endianness ,alignment,data types etc ?
If you adhere to the C standard, you should have no problems with
any of those, barring the use of binary files created or used by
other systems. That you can avoid by using text.
--
Chuck F (cbfal...@yahoo.com) (cbfal...@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!
Kevin Goodsell
>
> If you adhere to the C standard, you should have no problems with
> any of those, barring the use of binary files created or used by
> other systems. That you can avoid by using text.
>
Could you explain what specific problems you are referring to with
respect to binary files?
-Kevin
--
My email address is valid, but changes periodically.
To contact me please use the address from a recent posting.
nrk
> CBFalconer wrote:
>
>>
>> If you adhere to the C standard, you should have no problems with
>> any of those, barring the use of binary files created or used by
>> other systems. That you can avoid by using text.
>>
>
> Could you explain what specific problems you are referring to with
> respect to binary files?
>
> -Kevin
One problem that comes to mind is reading/writing using fread/fwrite
(structs, ints, floats etc.)...
-nrk.
Eric Sosman
>
> CBFalconer wrote:
>
> >
> > If you adhere to the C standard, you should have no problems with
> > any of those, barring the use of binary files created or used by
> > other systems. That you can avoid by using text.
> >
>
> Could you explain what specific problems you are referring to with
> respect to binary files?
For starters, see Question 20.5 in the comp.lang.c
Frequently Asked Questions (FAQ) list
http://www.eskimo.com/~scs/C-faq/top.html
... and don't forget to follow the links you'll find there.
Kevin Goodsell
Yes, but neither Chuck nor I would do that.
CBFalconer
> CBFalconer wrote:
>
> > If you adhere to the C standard, you should have no problems with
> > any of those, barring the use of binary files created or used by
> > other systems. That you can avoid by using text.
>
> Could you explain what specific problems you are referring to with
> respect to binary files?
For example, endianness, sizeof various entities, value of
CHAR_BIT, etc.
Kevin Goodsell
> Kevin Goodsell wrote:
>
>>
>>Could you explain what specific problems you are referring to with
>>respect to binary files?
>
>
> For example, endianness, sizeof various entities, value of
> CHAR_BIT, etc.
>
The only one of those that seems like a serious problem to me is
CHAR_BIT. Byte-order and the number of bytes for a given field would be
determined by the file format, which must be agreed upon by both sides
regardless of whether it's text or binary.
But, if the source and destination machine use different byte-sizes, I'm
not sure what you'd do, partly because I don't know how the file would
be translated. Obviously a file with 9-bit bytes moved to a machine with
8-bit bytes needs to be converted somehow. Suppose the conversion
consists of throwing away the high-order bit for each byte. In that
case, you just make sure you don't use that bit - limit yourself to the
8-bit range for each byte.
Jack Klein
wrote in comp.lang.c:
> Kevin Goodsell wrote:
> > CBFalconer wrote:
> >
> > > If you adhere to the C standard, you should have no problems with
> > > any of those, barring the use of binary files created or used by
> > > other systems. That you can avoid by using text.
> >
> > Could you explain what specific problems you are referring to with
> > respect to binary files?
>
> For example, endianness, sizeof various entities, value of
> CHAR_BIT, etc.
I'm curious, Chuck, because I know you're a long time embedded systems
programmer with experience on many different architectures, as I am.
Have you ever worked on a platform where CHAR_BIT was NOT 8? I've
done some Analog Devices SHARC work where CHAR_BIT was 32, and I'm
doing a lot of work on a TI 2812 DSP right now where CHAR_BIT is 16.
If you have worked on platforms where CHAR_BIT was greater than 8,
have they always had signed and unsigned char having the same
representation as signed and unsigned int (if not also signed and
unsigned long)?
Note that many standard functions, particularly all FILE * streams,
are impossible to implement on a platform where UCHAR_MAX == UINT_MAX,
since all file input if built on fgetc(), which can return any
unsigned character value from 0 to UCHAR_MAX, and EOF which must be a
negative integer and have a recognizably different bit pattern from
the above.
As for dealing with data internally on platforms with CHAR_BIT > 8,
it's not really all that hard. All the code in my chapter of C
Unleashed is "CHAR_BIT > 8" safe, because you only use the 8 least
significant bits an unsigned char and ignore anything else.
In the real world, I recently wrote both ends of a parser/formatter
for a proprietary CAN bus protocol. CAN messages (as you probably
know, but others might not) contain between 0 and 64 bits of data,
packed into 0 to 8 octets of 8 bits each.
My parser and formatter can pack and unpack various 8, 16, and 32 bit
values from any possible starting point in the data field of such a
packet into a signed or unsigned 8, 16, or 32 bit data object.
Since the processor on one side of the protocol was a TI DSP with
CHAR_BIT 16, it was written with "CHAR_BIT > 8" portability in mind.
The resultant source code compiles and runs properly both on the DSP
and on the other end of the CAN bus, where the ARM processor does have
8 bit character types.
There is only one tiny bit of surplus code to achieve that
portability. At one point there is an expression where an unsigned
char value is updated like this:
uc = (uc << 2) & 0xff;
...the mask is unnecessary when CHAR_BIT is 8 but is necessary on the
DSP because other parts of the code require all bits above 8 in the
unsigned char (if any) always be 0.
The value of CHAR_BIT is not much of a deterrent to portable code if
you give it a little thought and avoid using more than 8 of them even
when they are available.
--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++ ftp://snurse-l.org/pub/acllc-c++/faq
navin_2016
> CBFalconer wrote:
>
> >
> > If you adhere to the C standard, you should have no problems with
> > any of those, barring the use of binary files created or used by
> > other systems. That you can avoid by using text.
> >
>
> Could you explain what specific problems you are referring to with
> respect to binary files?
>
> -Kevin
I am trying to learn this thing. This is a hypothetical situtation.
I want to read an APPLE disk raw mode connected to an intel processor.
What are the issues that has to be handled.
Navin
-
CBFalconer
>
... snip ...
>
> I'm curious, Chuck, because I know you're a long time embedded systems
> programmer with experience on many different architectures, as I am.
>
> Have you ever worked on a platform where CHAR_BIT was NOT 8? I've
> done some Analog Devices SHARC work where CHAR_BIT was 32, and I'm
> doing a lot of work on a TI 2812 DSP right now where CHAR_BIT is 16.
>
>
> The value of CHAR_BIT is not much of a deterrent to portable code if
> you give it a little thought and avoid using more than 8 of them even
> when they are available.
No, I haven't actually run into the problem. But I see no reason
to ignore it (not that I am suggesting you do).
Grumble
> But, if the source and destination machine use different
> byte-sizes, I'm not sure what you'd do, partly because I don't
> know how the file would be translated. Obviously a file with
> 9-bit bytes moved to a machine with 8-bit bytes needs to be
> converted somehow.
Can somebody name one or more processors manufactured in 2003 where
CHAR_BIT is *not* a power of 2?
Flash Gordon
navin...@yahoo.co.in (navin_2016) wrote:
> Kevin Goodsell <usenet1.spa...@neverbox.com> wrote in message
> news:<2A5Bb.5952$rP6....@newsread2.news.pas.earthlink.net>...
> > CBFalconer wrote:
> >
> > > If you adhere to the C standard, you should have no problems with
> > > any of those, barring the use of binary files created or used by
> > > other systems. That you can avoid by using text.
> >
> > Could you explain what specific problems you are referring to with
> > respect to binary files?
>
> I am trying to learn this thing. This is a hypothetical situtation.
> I want to read an APPLE disk raw mode connected to an intel processor.
> What are the issues that has to be handled.
Raw disk access is a separate topic from binary file access. The
standard defines ways of handling binary files, but does not define ANY
way of doing raw disk access.
<OT>
In practical terms, it is completely impossible to read some disks on an
x86 platform with a typical BIOS unless you talk directly to the disk
controller. Even then, disks from some systems will be completely
unreadable as they use a different low level format. So you would need
to work out exactly what you want to do and ask somewhere else.
</OT>
--
Mark Gordon
Paid to be a Geek & a Senior Software Developer
Although my email address says spamtrap, it is real and I read it.
Dan Pop
>nrk wrote:
>
>> Kevin Goodsell wrote:
>>
>>>CBFalconer wrote:
>>>
>>>>If you adhere to the C standard, you should have no problems with
>>>>any of those, barring the use of binary files created or used by
>>>>other systems. That you can avoid by using text.
>>>>
>>>Could you explain what specific problems you are referring to with
>>>respect to binary files?
>>>
>>>-Kevin
>>
>> One problem that comes to mind is reading/writing using fread/fwrite
>> (structs, ints, floats etc.)...
>
>Yes, but neither Chuck nor I would do that.
That's highly irrelevant. The user has done that and you must write a
program to process his data.
And there are perfectly good reasons for writing binary files this
way, especially when size does matter. Just document the format of
each binary item in the file.
Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Dan...@ifh.de
Dan Pop
>CBFalconer wrote:
>
>> Kevin Goodsell wrote:
>>
>>>
>>>Could you explain what specific problems you are referring to with
>>>respect to binary files?
>>
>>
>> For example, endianness, sizeof various entities, value of
>> CHAR_BIT, etc.
>>
>
>The only one of those that seems like a serious problem to me is
>CHAR_BIT.
There was only one known platform with a conforming hosted
implementation having CHAR_BIT != 8. If portability to real world
hosted implementations is a concern, CHAR_BIT is the last thing I would
worry about.
The most important one is probably the very limited I/O capabilities
provided by standard C that effectively force people to use platform
specific extensions for both functionality and security related reasons.
As we all know, even something as trivial as suppressing terminal echo
or checking the availability of input in stdin are insoluble problems in
standard C.
>Byte-order and the number of bytes for a given field would be
>determined by the file format, which must be agreed upon by both sides
>regardless of whether it's text or binary.
If it's text, all you have to agree upon is a field separator and
optionally a maximum field length (useful to detect garbage input).
And a character set, of course :-)
Dan Pop
Do a Google search for "24-bit dsp". But the important thing is that
there are no hosted implementations for such processors.
Dan Pop
>I am trying to learn this thing. This is a hypothetical situtation.
>I want to read an APPLE disk raw mode connected to an intel processor.
>What are the issues that has to be handled.
Everything related to transferring the bytes from the disk to the memory.
Once you have the bytes in memory, you can process them with portable C
code (if you know what to do with them).
Keith Thompson
[...]
> There was only one known platform with a conforming hosted
> implementation having CHAR_BIT != 8. If portability to real world
> hosted implementations is a concern, CHAR_BIT is the last thing I would
> worry about.
Really? What platform is it? (I presume you're not talking about the
DS9000.)
--
Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://www.sdsc.edu/~kst>
Schroedinger does Shakespeare: "To be *and* not to be"
(Note new e-mail address)
Dan Pop
>Dan...@cern.ch (Dan Pop) writes:
>[...]
>> There was only one known platform with a conforming hosted
>> implementation having CHAR_BIT != 8. If portability to real world
>> hosted implementations is a concern, CHAR_BIT is the last thing I would
>> worry about.
>
>Really? What platform is it? (I presume you're not talking about the
>DS9000.)
The C89 implementation for the Univac 1100 (or something like that) had
9-bit char's and it was also (in)famous for using one's complement
arithmetic.
Such characteristics were not exactly uncommon once upon a time, but this
is the only such hardware platform with a C89 implementation that I'm
aware of.