PPC or i386 ?

Wed Mar 10 09:07:01 2004

For completeness sake, I will elaborate a bit on this:

A source rpm contains the source code to a certain program. If the 
source code is written with platform independence in mind, then you can 
build the program on any platform it was designed for, be it PPC of x86 
with the right tools on each specific platform.

This is rather general, so let's look at it a bit more specifically. 
Platform independance is largely dependant on the program language being 
used for the program.
There are four main groups of programming languages I'll discuss here:
- assembly language
- higher level languages, such as C, C++, Cobol, Fortran, ...
- java
- scripting languages

Assembly language
-----------------
PPC and x86 processors have a totally incompatible instruction set. This 
means there exists an assembly language for PPC and an assembly language 
for x86 that are not interchangeable. So if the program or part of the 
program you are trying to build on PPC is written in x86 assembly 
language, you are out of luck. A PPC processor can't read the x86 
language, and hence will choke on it.
A programmer that wants his programs to run on both PPC and x86 should 
either stay away from assembly language, or write the code twice: once 
in x86 language and once in PPC language, and pack both in the source rpm.

Higher level languages
----------------------
C and C++ (and others) are higher level languages that are designed to 
create platform independant SOURCE CODE. From this code, a program 
(binary) can be built for each platform, but each binary is built only 
for ONE SPECIFIC PLATFORM.
Since C and C++ compilers are available both for the x86 as the PPC 
platform (and many other by the way) you could build a binary for PPC 
and a binary for x86 from the same source.

There is one subtle caveat however: data on is stored differently on PPC 
systems versus x86 systems, both in memory as on disk.
PPC systems are said to be "big endian", while x86 systems are "little 
endian". This is a complex term to indicate that both systems use a 
different ordering of bits and bytes in memory.
To explain this, I'll use a parallel with writing: it's a bit like 
western languages writing from left to right, while asian languages 
write from right to left (and top-down first even as well!). As long as 
a chinese text is written right to left any chinese could read it. In 
the same way a western man could easily read a western text written from 
left to right.
Now suppose a not too clever chinese wants to write a text for a western 
person, but gets the direction all wrong, and he writes from right to 
left. The text "Can you read this from left to right" would suddenly become:
thgir ot tfel morf siht daer uoy naC

If a regular westerling tries to read this from left to right, he would 
only see rubbish. It simply doesn't make any sense.

Simplified, that is also what can happen when data is shared between PPC 
and x86. If a program is not carefully written, the binary built for x86 
would read and write data in reverse order compared to the binary built 
for PPC. This could result in a program that handles data correctly on 
one system, and falsely on the other. This is most commonly a problem 
for binary data such as music (mp3) and video (mpeg/avi).
Well designed programs though take this "endian-nes" into account and 
deal with it correctly.

The conclusion for higher level languages is that although programs 
written in C/C++ are mostly buildable on different platforms, it depends 
a bit on wether the programmer dealt with all endian issues.

Java
----
Java (and other recent languages like C#) was designed as an evolution 
on the higher level languages. Java enables a programmer to write 
platform independant source code (like with the other high level 
languages) AND build this into platform independant binaries.
Hence you are unlikely to find x86 or PPC specific rpms for programs 
written in java. Instead such rpms most likely are named "noarch".
Since a pure java program works on both platforms, you have fewer 
reasons to search for a source rpm for a java program. They can exist 
however, and you can be fairly sure that you could build such a source 
rpm on both platforms with no problems.

On a sidenote, I don't know Java enough to say wether or not endian 
issues can still arise when writing java programs. I assume that these 
issues should be dealt with in the runtime library for each specific 
platform, and thus neither programmer, nor user should be concerned. But 
this is just my assumption.

Scripting languages
-------------------
Lastly there are programs written in scripting languages such as Python, 
Perl, and so on. The difference between scripts and other programming 
languages is that scripts don't need to be built. An interpreter reads 
the script and executes whatever the programmer had in mind. Programs 
written in a classic programming language need to be built 
(compiled/assembled/linked) into a binary before they can be run.

If an interpreter for a certain scripting language exists on both 
platforms, a program in that scripting language can run on both 
platforms. For the most common scripting languages, such as pearl, 
python, lisp, and so on, there is effectively an interpreter available, 
so programs written in these scripting languages work on both platforms.

On a sidenote, since scripts, even complete programs in scripts, don't 
need to be built in order to be used, they are usually packaged in 
platform independant rpms (named "noarch").

There you go. I hope this helps people understand better why some rpms 
can and other can't be built on different platforms.

Cheers
Geert

Jeroen Zwartepoorte wrote:
> Hi Dan,
> 
> There are no specific ppc or i386 source rpms. A .spec file can only
> specify that it can build packages for i386 or ppc (a kernel rpm for
> example), but source rpms in general can be built for any platforms
> which supports rpms.
> 
> Jeroen
> 
> On Wed, 2004-03-10 at 07:31 -0600, Dan Kahmann wrote:
> 
> 
>>I know this is probably a really dumb think to ask (I should know
>>better !?) 
>>but here it is -
>>When building from source ( any app ) with YDL , must you use a source
>>that is specifically for PPC , or can you use any source (linux) ?
>> 
>>If you must use PPC sources, then might there be a tool to help
>>convert 
>>the i386 to PPC , or does it require a complete re-write of the
>>source ?
>> 
>>As this is my first experience with apple/mac , I just don't know that
>>much about them, 
>>except that there is alot of differences btween the Motorolla PPC's
>>and any Intel based
>>processors...
>> 
>>T/c 
>>Dan
>> 
>> 
>> 
>>Dan Kahmann
>>dkah197@earthlink.net
>>Why Wait? Move to EarthLink.
>> 
>>
> 
> 
> _______________________________________________
> yellowdog-general mailing list
> yellowdog-general@lists.terrasoftsolutions.com
> http://lists.terrasoftsolutions.com/mailman/listinfo/yellowdog-general
> HINT: to Google archives, try  '<keywords> site:terrasoftsolutions.com'
> 
> 
> 