T
Tomás Ó hÉilidhe
(One dodgy click of the mouse and the previous thread got posted
prematurely. Here's the proper thread.)
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
compile it on an Apple Mac that has a PowerPC processor.
Now of course I know a lot of people who frequent this forum aim to
write fully-portable programs where possible, but at some stage you
might have the source code for a particular program and want to
compile it for a different kind of CPU that it was originally intended
for.
A good example of this is with Linux. Different binaries of the Linux
operating system can be gotten for different CPU types, so two
different computers with two different CPU's can essentially have the
same operating system. You might download the source code for a
program which you know runs well on an x86 computer, but you're weary
that it might contain some non-portable features that will cause it to
malfunction on your PowerPC. So with that in mind, I'd like to draw up
a finite list of things that can change with CPU type and that may
influence a C program.
Well the obvious ones are:
1) Integer type sizes and ranges (CHAR_BIT, INT_MAX, sizeof(int),
etc.) (Yes I realise these are more to do with the compiler, but many
compilers reflect the underlying machine)
2) The presence or lack thereof of padding in integer types (it's
extremely rare as far as I know to have padding in integer types)
3) The assumption that all-bits-zero is valid for null pointers
and floating-point numbers (by the way has there ever been a system
where this wasn't so?)
4) Byte order in integer types (e.g. little endian, big endian)
5) Alignment requirements for types.
If you're writing fully-portable programs, then none of these should
be a problem. However if you're writing a specialised program, for
instance a networking program, then you might enforce some non-
portable assumptions; for instance a common assumption in networking
programming is that CHAR_BIT == 8.
You might come across a program that assumes the CPU to be little
endian, and this will be a problem if the program does networking.
I can't think of any more thing off hand to watch out for, but the
reason I'm posting here is that I get the feeling there could be a big
one that I hadn't thought of. If anyone can think of anything to watch
out for, please reply.
prematurely. Here's the proper thread.)
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
compile it on an Apple Mac that has a PowerPC processor.
Now of course I know a lot of people who frequent this forum aim to
write fully-portable programs where possible, but at some stage you
might have the source code for a particular program and want to
compile it for a different kind of CPU that it was originally intended
for.
A good example of this is with Linux. Different binaries of the Linux
operating system can be gotten for different CPU types, so two
different computers with two different CPU's can essentially have the
same operating system. You might download the source code for a
program which you know runs well on an x86 computer, but you're weary
that it might contain some non-portable features that will cause it to
malfunction on your PowerPC. So with that in mind, I'd like to draw up
a finite list of things that can change with CPU type and that may
influence a C program.
Well the obvious ones are:
1) Integer type sizes and ranges (CHAR_BIT, INT_MAX, sizeof(int),
etc.) (Yes I realise these are more to do with the compiler, but many
compilers reflect the underlying machine)
2) The presence or lack thereof of padding in integer types (it's
extremely rare as far as I know to have padding in integer types)
3) The assumption that all-bits-zero is valid for null pointers
and floating-point numbers (by the way has there ever been a system
where this wasn't so?)
4) Byte order in integer types (e.g. little endian, big endian)
5) Alignment requirements for types.
If you're writing fully-portable programs, then none of these should
be a problem. However if you're writing a specialised program, for
instance a networking program, then you might enforce some non-
portable assumptions; for instance a common assumption in networking
programming is that CHAR_BIT == 8.
You might come across a program that assumes the CPU to be little
endian, and this will be a problem if the program does networking.
I can't think of any more thing off hand to watch out for, but the
reason I'm posting here is that I get the feeling there could be a big
one that I hadn't thought of. If anyone can think of anything to watch
out for, please reply.