«

I would like to draw up a finite list of things you have to "watch out
for" when compiling a C program for a different kind of CPU than it
was originally intended for. For instance, let's say you have a C
program that was intended to run on an x86 processor, but you want to
run it on an Apple Mac that has a PowerPC processor.

Well the obvious ones are:

Tomás Ó hÉilidhe wrote:
> I would like to draw up a finite list of things you have to "watch out
> for" when compiling a C program for a different kind of CPU than it
> was originally intended for. For instance, let's say you have a C
> program that was intended to run on an x86 processor, but you want to
> run it on an Apple Mac that has a PowerPC processor.
>
> Well the obvious ones are:

The entirety of Annex J to the C standard is a good starting point.
I'm not sure whether it's comprehensive, though - it's only 27 pages
long, which doesn't seem sufficient to provide complete coverage.

In article <b15bd7b2-b6d2-40bc-af78->,
Tomas S hIilidhe <> wrote:
>
>I would like to draw up a finite list of things you have to "watch out
>for" when compiling a C program for a different kind of CPU than it
>was originally intended for.

Draw up your finite list.
Show it to a CPU designer with a contrarian streak.
The next version of the CPU architecture will have a difference not
accounted for on your list.

Therefore, no such finite list can exist.


The solution, of course, is to write to the interface defined by the
standard instead of making assumptions about the CPU; making it work
with a different CPU then becomes the compiler implementor's problem.


dave

--
Dave Vandervies dj3vande at eskimo dot com
>Is it me or is the intelligence in here dropping like a stone?
It's just you. Unless the stone is made of Neutronium.
--Dave Brown and Shmuel (Seymour J.) Metz in the scary devil monastery

On Dec 4, 10:04*am, Tomás Ó hÉilidhe <t...@lavabit.com> wrote:
> I would like to draw up a finite list of things you have to "watch out
> for" when compiling a C program for a different kind of CPU than it
> was originally intended for. For instance, let's say you have a C
> program that was intended to run on an x86 processor, but you want to
> run it on an Apple Mac that has a PowerPC processor.
>
> Well the obvious ones are:

Byte sex (endianess)
Alignment restrictions
Type sizes

John Bode wrote, On 04/12/08 16:55:
> On Dec 4, 10:04 am, Tomás Ó hÉilidhe <t...@lavabit.com> wrote:
>> I would like to draw up a finite list of things you have to "watch out
>> for" when compiling a C program for a different kind of CPU than it
>> was originally intended for. For instance, let's say you have a C
>> program that was intended to run on an x86 processor, but you want to
>> run it on an Apple Mac that has a PowerPC processor.
>>
>> Well the obvious ones are:
>
> Byte sex (endianess)
> Alignment restrictions
> Type sizes

With floating point there is a lot more than just the type size!
CHAR_BIT (and everything else in limits.h)
Division of negative values
Timings (if they matter)
Extensions (ones used by the SW you are porting)
Availability of a compiler for the version of the C standard the code
conforms to (especially if it is C99 code)
Legal paths/filenames
Limits on program/data sizes
Whether it uses text/binary streams correctly
Anything the standard says in implementation defined
Use of anything the standard leave as unspecified or undefined

It goes on and on if you are talking about some random program. Writing
a program to be portable in the first place can be rather easier.
--
Flash Gordon
If spamming me sent it to
If emailing me use my reply-to address
See the comp.lang.c Wiki hosted by me at http://clc-wiki.net/

Tomás Ó hÉilidhe wrote:

> I would like to draw up a finite list of things you have to "watch out
> for" when compiling a C program for a different kind of CPU
>
> Well the obvious ones are:

My two cents worth

1) There are a ton of things that are related to function argument passing.
Stack frames, compile time local allocation, register passing.

2) The misra list is worth looking through. It raises a lot of implementation
defined points.

3) Variable packing, union and struct allocation.

4) Language symbol representation.

Regards,

--
Walter Banks
Byte Craft Limited
http://www.bytecraft.com

Tomás Ó hÉilidhe wrote:
>
> I would like to draw up a finite list of things you have to "watch
> out for" when compiling a C program for a different kind of CPU
> than it was originally intended for. For instance, let's say you
> have a C program that was intended to run on an x86 processor, but
> you want to run it on an Apple Mac that has a PowerPC processor.

If you simply pay attention to the C standard and write properly
compliant code, you will have nothing to "watch for".

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.

CBFalconer <> writes:
> Tomás Ó hÉilidhe wrote:
>> I would like to draw up a finite list of things you have to "watch
>> out for" when compiling a C program for a different kind of CPU
>> than it was originally intended for. For instance, let's say you
>> have a C program that was intended to run on an x86 processor, but
>> you want to run it on an Apple Mac that has a PowerPC processor.
>
> If you simply pay attention to the C standard and write properly
> compliant code, you will have nothing to "watch for".

That's not always possible, especially if you're working with code
that somebody else wrote or that's deliberately non-portable (there
are often good reasons for the latter).

--
Keith Thompson (The_Other_Keith) kst- <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

On Dec 4, 4:17*pm, CBFalconer <cbfalco...@yahoo.com> wrote:
> Tomás Ó hÉilidhe wrote:
>
> > I would like to draw up a finite list of things you have to "watch
> > out for" when compiling a C program for a different kind of CPU
> > than it was originally intended for. For instance, let's say you
> > have a C program that was intended to run on an x86 processor, but
> > you want to run it on an Apple Mac that has a PowerPC processor.
>
> If you simply pay attention to the C standard and write properly
> compliant code, you will have nothing to *"watch for".
>
> --
> *[mail]: Chuck F (cbfalconer at maineline dot net)
> *[page]: <http://cbfalconer.home.att.net>
> * * * * * * Try the download section.

For example,

short *p;
char *q;
*p = *(short*)q;

this type of code works on some platforms, but will break on some
others.

litchie wrote:
....
> For example,
>
> short *p;
> char *q;
> *p = *(short*)q;
>
> this type of code works on some platforms, but will break on some
> others.

What does "works" mean in this context? The behavior is undefined for
several different reasons, and will typically fail for at least one of
those reasons on every platform I normally work on. However, even if
the behavior were defined, what would you expect that behavior to be?