This is pretty cool I think.

http://zero.eik.bme.hu/~balaton/qemu/amiga/

https://www.google.com/url?q=http://zero.eik.bme.hu/~balaton/qemu/amiga/&sa=U&ved=0ahUKEwjSqZnX0-XcAhUk04MKHZ9uD4MQFggqMAg&usg=AOvVaw0X0AF6QhFMO7ZyKsM808ka

The above link gives info on running Aros Sam 440 on qemu.
I look to check this out on my day off.

Not meaning it was exempt, just tailored (?) to it.

What I've said before applies to Hollywood as well...

I am going to leave it where it is.
I think Hollywood is a good case.
It has a compiler for each supported platform.

Porting software is not difficult if you know:
- the language specs;
- the platforms specs;
- how to deal with data formats (like michalsc explained).

Usually a developer should know that stuff. Unless he moved too quickly from the hoe to the keyboard...
<Grin>

I guess porting software is never perfect.
As you all can see, I dig around in too much technology.
Grin.

Thanks.
My flow chart stencil handles all kinds. ????

I'm hoping that a 64-bit compiler on one CPU has taken care of some of the changes that would come from another 64-bit CPU of a different platform, being the same language.

I do not want to reiterate the same old comments.

Quote:

No, they are not. It's not about the language you use, it's only about the data you want to work with. Even with high-level language you have to deal with endianness if you e.g. parse or produce any binary data with types of size exceeding the byte. Yes, the languages have often some conversion utilities (like Python's struct with it's pack and unpack functions), but you are forced to deal with them.

Or, if you don't want to, then just stick to textual representations of data and work with that :)

Double Post.