How to add Little Endian support to OS? (for easier porting)

A forum for general AmigaOS 4.x support questions that are not platform-specific

Re: How to add Little Endian support to OS? (for easier port

Postby ChrisH » Wed Jun 29, 2016 2:39 pm

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 ...)

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?)

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.

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.

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.

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).

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).

This sounds similar to Xenic's suggestion, which is an interesting idea... but please discuss it in a different thread. :-)
Last edited by ChrisH on Wed Jun 29, 2016 3:02 pm, edited 1 time in total.
User avatar
ChrisH
Beta Tester
Beta Tester
 
Posts: 912
Joined: Mon Dec 20, 2010 10:09 pm

Re: How to add Little Endian support to OS? (for easier port

Postby ChrisH » Wed Jun 29, 2016 2:51 pm

@xenic
I was hoping you would explain why my proposal is non-viable :( . I don't see why that would require explaining an entirely different technical solution... (And as I said, you are welcome to start a different thread discussing that different solution - I might even take part. I just want to prevent this thread getting too complex for anyone else to bother trying to follow it.)

BTW, I'm not especially smart! Just fairly stubborn at solving problems which interest me ;-)
User avatar
ChrisH
Beta Tester
Beta Tester
 
Posts: 912
Joined: Mon Dec 20, 2010 10:09 pm

Re: How to add Little Endian support to OS? (for easier port

Postby Belxjander » Wed Jun 29, 2016 4:10 pm

ChrisH wrote:
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 ...)

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?)



Inline BE mode compiled values are immediate reads of BE byte order... LE mode would read them byte reversed.
PPC assembler splits hi and lo 16bit words as independent RISC instructions...to build 32bit values
This means you would get 2x 16bit BE values reversed and put correctly into hi and lo halves of a 32bit register...
2301 instead of 3210 making it correct for a PDP-11 but incorrect for both BE and LE formats as a 32bit value.
That is how I am reading the little green book here.

Unless we use an abused form of UTF encoding for 32bit values to decode correctly regardless of processor.
(Something I considered after dealing with UTF-8 for Japanese... But using arbitrary 32bit values encoded that way instead of using it for expanded textual symbol support, the in-register 32bit result is Endian ignorant and only requires sequential octet processing, therefore possibly a door between BE & LE for consistent value transfers).

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.

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.
[/quote
]
How to "Enter/Exit" the container native LE mode for BE Host access... UTF8 style octet encoding/switch/decoding for function argument vectors beyond registized arguments makes sense here to limit switching overhead.

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.

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).

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).

This sounds similar to Xenic's suggestion, which is an interesting idea... but please discuss it in a different thread. :-)


Switching to private... This "container with proxy" is something I'm already messing with...
And I've ignored mode switching the CPU going with different design decisions (assuming no motherboard support),
Leaving some options open though... And have some potentially weird use-case options that I'm not sure are practical/useful...

Definitely need a second opinion or three for the proxy part...wanting to limit hand-assembly to essentials only
Belxjander
 
Posts: 275
Joined: Mon May 14, 2012 11:26 pm
Location: 日本千葉県松戸市 / Matsudo City, Chiba, Japan

Re: How to add Little Endian support to OS? (for easier port

Postby tonyw » Thu Jun 30, 2016 2:04 am

Belxjander wrote:This means you would get 2x 16bit BE values reversed and put correctly into hi and lo halves of a 32bit register...
2301 instead of 3210 making it correct for a PDP-11 but incorrect for both BE and LE formats as a 32bit value.


If a PPC instruction containing immediate data is split into two 16-bit words, then are those two words reversed endian-wise? I would guess not, since they are in I-space, not D-space.

In any case a 16-bit word such as 2301 (which consists of two bytes 23.01) will be reversed to read 01.23, not 32.10. The individual bytes are not reversed, only the order of the bytes. That is what makes endian conversion so slow in software - you have to swap between 0x12.34.56.78 and 0x78.56.34.12.

One of these days when I have nothing to do, I must read the p5020 Ref Manual on the subject...
cheers
tony
User avatar
tonyw
AmigaOS Core Developer
AmigaOS Core Developer
 
Posts: 1302
Joined: Wed Mar 09, 2011 2:36 pm
Location: Sydney, Australia

Re: How to add Little Endian support to OS? (for easier port

Postby Belxjander » Thu Jun 30, 2016 2:20 am

tonyw wrote:
Belxjander wrote:This means you would get 2x 16bit BE values reversed and put correctly into hi and lo halves of a 32bit register...
2301 instead of 3210 making it correct for a PDP-11 but incorrect for both BE and LE formats as a 32bit value.


If a PPC instruction containing immediate data is split into two 16-bit words, then are those two words reversed endian-wise? I would guess not, since they are in I-space, not D-space.

In any case a 16-bit word such as 2301 (which consists of two bytes 23.01) will be reversed to read 01.23, not 32.10. The individual bytes are not reversed, only the order of the bytes. That is what makes endian conversion so slow in software - you have to swap between 0x12.34.56.78 and 0x78.56.34.12.

One of these days when I have nothing to do, I must read the p5020 Ref Manual on the subject...


Thank you for the correction, that makes more sense.

I'll have to go through some notes here again and recheck to see where I may have errors from working on things when tired.
Belxjander
 
Posts: 275
Joined: Mon May 14, 2012 11:26 pm
Location: 日本千葉県松戸市 / Matsudo City, Chiba, Japan

Re: How to add Little Endian support to OS? (for easier port

Postby Amigo1 » Mon Jul 04, 2016 11:09 am

@belxjander
@tonyw
@chrisH
@xenic

Very interesting read, thanx.
User avatar
Amigo1
 
Posts: 176
Joined: Sun Jan 01, 2012 4:32 pm

Re: How to add Little Endian support to OS? (for easier port

Postby Belxjander » Mon Jul 04, 2016 11:01 pm

tonyw wrote:
Belxjander wrote:This means you would get 2x 16bit BE values reversed and put correctly into hi and lo halves of a 32bit register...
2301 instead of 3210 making it correct for a PDP-11 but incorrect for both BE and LE formats as a 32bit value.


If a PPC instruction containing immediate data is split into two 16-bit words, then are those two words reversed endian-wise? I would guess not, since they are in I-space, not D-space.

In any case a 16-bit word such as 2301 (which consists of two bytes 23.01) will be reversed to read 01.23, not 32.10. The individual bytes are not reversed, only the order of the bytes. That is what makes endian conversion so slow in software - you have to swap between 0x12.34.56.78 and 0x78.56.34.12.

One of these days when I have nothing to do, I must read the p5020 Ref Manual on the subject...


Let me know if like the rest of the PowerPC ref manuals it only handles hardware details specific to that model.

The PowerPC programmers reference manual that I have here doesn't't deal with hardware beyond what *will and *may* be in the actual processor
Belxjander
 
Posts: 275
Joined: Mon May 14, 2012 11:26 pm
Location: 日本千葉県松戸市 / Matsudo City, Chiba, Japan

Previous

Return to General AmigaOS

Who is online

Users browsing this forum: Google [Bot] and 8 guests

cron