MorphOS on x86???

[Hans_]

arnljot wrote:
The never endian(-ess) endian issue is also brought up.

But AROS must partly have addressed that issue since they now are on PPC and x86

AROS solves the endianness issue by not trying to have binary compatibility. Thus, AROS PowerPC software won't run on x86 and vice versa.

So, if one were to ditch compatibility with every single MorphOS program out there today, sure, it would be easy. Otherwise, writing an emulator for existing software that integrates properly with the system would be a huge task.

Hans

[Hans_]

trekiej wrote:
I wonder if those who have an OS that is big and little endian per cpu have a developement tool chain capable of handling both?
How did BeOS cope?

No idea about BeOS, but it's common to have a header file such as endian.h that indicates which type the current CPU uses. Most software developers don't have to worry about endianness, but when you start doing things that access hardware directly, or read/write stuff to/from disk or streams, CPU endianness does make a difference. For example, a CD/DVD-writer app for AROS would have to take CPU endianness into account as it accesses the CD/DVD drive at a low level. Otherwise, it would work either on AROS x86, or on PowerPC, but not both.

Hans

[Hans_]

trekiej wrote:
I have done some C programming and wanted to know if some one could give us a good example of when endianess becomes an issue. I bet this has been a subject many times before.

Have a look at the source-code to cd-record. Specifically, look at the file scsimmc.h. You'll see that the bit-fields are inverted, depending on the endianness of the CPU. There will also be other, non-bitfield issues too.

Hans