megatron-uk wrote:

Because you don't write x86/ppc/arm code. […]
Show full quote

sliderider wrote:

"and no, again your lack of knowledge, these days, for true porting, you can reuse almost all of the code. Most of the times you just need some ifdef PLATFORMNAME and a compiler targeting that platform."

So tell me then, how do you port a game written in x86 code to say, a PowerPC processor, and still use the x86 code? How does the PowerPC processor interpret and run the code? You have to discard the x86 code and replace it with PowerPC code. I don't care if you use something like a cross compiler to translate x86->PowerPC, the finished product on the PowerPC machine still is NOT running x86 code. There is ZERO x86 code in the finished port.

Because you don't write x86/ppc/arm code.

You write in C/C++, or an equivalent, which is a (mostly) platform agnostic language. That code (which is simply text, there's nothing about it that ties it to one cpu architecture or another) is then turned into an executeable binary (your 'x86 code') by a compiler and linked to any supporting library routines (eg for input/output, audio playback, video compression etc).

As long as someone supplies a working c compiler, linker and the correct libraries, your C code will compile to a runnable programme for any platform.

It seems as though you believe that everything is written in assembly language, or even machine code specific to the host machine. That may have been true in 8bit and early 16bit home computer era, but it hasn't been the case for a long, long time.

C is a language that still has to be translated into native code that the target CPU can understand at the instruction set level. You might be able to code in a high level language on any machine, but the CPU still has to be able to execute it using commands from it's native instruction set. An Intel system still understands only x86 instructions, regardless of what high level language you use. It does not run C code directly. When you compile, it becomes instructions that the CPU can use. If you compile for x86, that same compiled code will NOT run on a 68k or PowerPC machine. You have to compile it into those machines' own native instructions to run it. Why isn't anyone understanding that?

Because that is not a code but compiler issue

Dominus wrote:

Because that is not a code but compiler issue

But the finished code is still not the same code. You may have started with the same high level code, but after compiling for both it is two different programs in two different machine languages.

The code is the same. The binary is different

I remember back when this thread was about Icewind Dale II. Now it's just a pedantic shitstorm. Chill out, homies.

Dominus wrote:

The code is the same. The binary is different

Only the high level code is the same. The low level machine language code is not, and that is the point I was trying to make so why were you arguing with me at all?

Because you made it an issue. Whatever the compiler does is of no importance in regard to porting
That the binaries for one platform won't run on another is nothing anyone here objected to. But the code of the program stays the same.

Example of a simple hello world program:

1#include <iostream>
2
3using namespace std;
4
5int main()
6{
7	cout << "Hello Sliderider - don't forget your meds!" << endl;
8	return 0;
9}

Save that as hellomeds.cpp and compile it with different compilers for different platforms. The code will never be touched and will stay the same. The compiled binary won't run on another platform but it doesn't need to and all that crap you are newly arguing about is of no interest since that is done by the compiler.
On more advanced code you might need to put an "ifdef platformname" and some instructions how to behave on that platform. That's how you port a program. You do it with the source code *NOT* the binary.

As you don't seem to understand, the source code is what matters. You always refer to "finished code", as if the compiler would change the code. It doesn't. The source code of a program is the finished code. After you let the compiler run over the source code you get a binary and yes that is refered to as "machine code" or "machine language". But that is of no importance.

So tell me then, how do you port a game written in x86 code to say, a PowerPC processor, and still use the x86 code? How does the PowerPC processor interpret and run the code? You have to discard the x86 code and replace it with PowerPC code. I don't care if you use something like a cross compiler to translate x86->PowerPC, the finished product on the PowerPC machine still is NOT running x86 code. There is ZERO x86 code in the finished port.

do you get this now? You don't port the binary/machine code, you port the source code which is not tied to a platform (well it can be tied to one, hence the ifdef).

"As you don't seem to understand, the source code is what matters. You always refer to "finished code", as if the compiler would change the code. It doesn't. The source code of a program is the finished code. After you let the compiler run over the source code you get a binary and yes that is refered to as "machine code" or "machine language". But that is of no importance. "

That is what's important because that is what I was talking about all along. You are the one who introduced all sorts of irrelevant concepts to the discussion. I said that x86 code only runs on x86 processors and you disagreed with me. I think you are the one who needs meds.

And yes, the compiler DOES change the source code otherwise it isn't doing it's job. The job of the compiler is to convert the high level language into machine specific code. To do that, it has to change the code going in into something else coming out and if you are compiling for multiple platforms, then the output specific to each platform will be different from all the others regardless of what goes into the compiler.

No, I never wrote either. I think one of your linited abilities allows you to quote, please use that to ahow where I wrote that,

You asked:

So tell me then, how do you port a game written in x86 code to say, a PowerPC processor, and still use the x86 code? How does the PowerPC processor interpret and run the code? You have to discard the x86 code and replace it with PowerPC code. I don't care if you use something like a cross compiler to translate x86->PowerPC, the finished product on the PowerPC machine still is NOT running x86 code. There is ZERO x86 code in the finished port.

and I tried to answer this.

But once more, a game is NOT written in x86 code, it is written in a programming language and then translated by the compiler in the machine language of the target platform.

And no the compiler DOES NOT change the code. It READS the code and WRITES the binary in machine code. a compiler that changes the source code would be a very bad thing...

You have to keep your words straight:
Code is generally what source code is refered to. Source code is just a whole bunch of text files.
Machine code is what people refer to as the binary in which the compiler translates the source code.
If you say code people think of the source code and not machine code.

So to answer it again, to port a game you don't change the binary/machine code, you change the source code to make it compilable for another target platform. That's porting.

Now if you don't have the source code but only the binary/machine code (for example only the x86 binary) then you can't port the game. You will have to remake the program ->
GemRB is not a port BUT a remake.

Your whole concept of how a computer program is written seems to be fundamently flawed.
No one ever says "a game is written in x86 code (or powerpc or arm)".
One says "a game is written in C++ (or C, or Java or Turbo Pascal...) and compiled for Windows (or Linux or OS X, or Android...)".

Dominus wrote:

Your whole concept of how a computer program is written seems to be fundamently flawed.
No one ever says "a game is written in x86 code (or powerpc or arm)".
One says "a game is written in C++ (or C, or Java or Turbo Pascal...) and compiled for Windows (or Linux or OS X, or Android...)".

I never said any game was written only in machine code. What I said was each processor only understands one language and that is the language of the instruction set that is built into it, and that is perfectly true. Then you come along and go off on an irrational rant about high level languages. What you call a binary is also code. The binary is the code that the specific CPU understands at the lowest level.

And when it comes down it, from a certain perspective, every program ever written IS written in machine code. The high level language and the compiler act as an intermediary between the programmer and the low level machine code that the CPU understands to make the job of writing the program easier.

Look at this way, if you did not understand English then I would have to speak to you in the language that you do understand or hire an interpreter who speaks both. The high level programming language would be like the language that I speak while the CPU specific instructions that are hard coded into the CPU would be the language that you speak. The compiler would be the interpreter that translates what I am saying into a language that you can understand. Why are we not in agreement on this?

Well, you brought the binaries into play but that is not needed for porting a program. You only need the source code and that is platform independant.
You brought this into the discussion with

So tell me then, how do you port a game written in x86 code to say, a PowerPC processor, and still use the x86 code?

To that I have to answer that games or programs are NOT written in x86 code. They are written in a programming language and only by the compiler translated into platform specific "code" (binary). Hence you don't need to port the x86 "code" but the source code.
Then you brought higher lower code into the discussion, not me.

Lol I love this conversation, it just keeps repeating itself because sliderider doesn't know when to give up and just say he was wrong.

*Closed* This leads nowhere.