Hmmm, I'm not sure this is actually a problem. Endianness is only an issue when a value is written byte-wise but read word wise (or vice versa). This can only happen for memory access (AFAIK), and so cannot happen for immediate values (stored as part of an instruction), so I don't yet see the problem. (But I haven't touched assembler for years, and never touched PPC assembler, so I may well be missing something obvious?)Belxjander wrote:Compilers produce a LOT of "li" values in PPC compilation along with 16b and 32b values inlined directly into the ".text" section.
Without any means of marking these inline values, access to any of them immediately veto's use of the MMU to magic-convert the value at runtime. (This also introduces more mixed-endian headaches ...)
Certainly I was imagining LE mode to be implemented at OS level (integrated into Exec), and I already mentioned the idea that Library calls would need automatic wrappers to prevent Library code from running in LE mode. I don't see this as a problem, per se.For a "little endian" mode, the entire program using this mode would require interfaces for LE mode calling AND the entire program to be switched to LE mode at compilation.
Basically requiring wrapper interfaces and an OS level "Container" implementation to be built into the OS.
Thanks for reporting this. It's something that would need to be checked before doing much real work on this idea... I guess it would be OK as long as most of the recent Amiga motherboards support it, even if older ones did not. Hell, even if just one motherboard supported it, it would greatly ease porting issues, as you could port something without worrying (much) about Endian issues, and then once it worked THEN look at dealing with Endian issues (i.e. turn off Endian magic & then fix new crashes which must be due to Endian problems).As for the PPC/LE mode, not all of the PPC processors allow the use of the facility without motherboard support.
The LE option is documented as needing motherboard support (with nothing mentioned beyond this point) in the little green book I have with me.
This sounds similar to Xenic's suggestion, which is an interesting idea... but please discuss it in a different thread.If you are going to make container facilities available, then isolate the entire ported app to within a fixed and limited minimal runtime with possibly emulating the processor? This would require OS function wrappers (Emulation or not).