Endianess

[Tristan Miller]

Hey,

   Sorry, having problems with internet or else I'd ask this on IRC.  I was
curious as to why the emphasis on little-endian mode in powerpc.  Mac G5's
don't even have le-mode, and it definitely seems that (although im not
totally sure, as theres not much info out in the wild yet) that the XBox360
lacks le-mode as well.  Also, on the processors that support le-mode, it
seems in all cases (although theres probably some embedded guy that I'm
missing : P) that do support it, it's selectable at the minimum at the
user/supervisor level with only a bit of work.  Perhaps eventually a
thunking layer (maybe a part of NTVDM, would it need to be that complex?)
that would translate the calls from le usermode to a be kernel could be
written, allowing one to run NT-PPC applications that are out there.  We
wouldn't be able to load drivers (or any le kernel code), but are there
actually any PPC drivers out in the wild?  Plus, it seems that it would
definitely be a good thing for the kernel source to be tested  on multiple
endians as early as possible in its development to ease porting later on.

   ~ Tristan Miller
      (monocasa)

[art yerkes]

On Sun, 11 Mar 2007 05:58:48 -0400
"Tristan Miller" <trismandev(a)gmail.com> wrote:

>   Hey,
>  
>     Sorry, having problems with internet or else I'd ask this on IRC.  I was
>  curious as to why the emphasis on little-endian mode in powerpc.  Mac G5's
>  don't even have le-mode, and it definitely seems that (although im not
>  totally sure, as theres not much info out in the wild yet) that the XBox360
>  lacks le-mode as well.  Also, on the processors that support le-mode, it
>  seems in all cases (although theres probably some embedded guy that I'm
>  missing : P) that do support it, it's selectable at the minimum at the
>  user/supervisor level with only a bit of work.  Perhaps eventually a
>  thunking layer (maybe a part of NTVDM, would it need to be that complex?)
>  that would translate the calls from le usermode to a be kernel could be
>  written, allowing one to run NT-PPC applications that are out there.  We
>  wouldn't be able to load drivers (or any le kernel code), but are there
>  actually any PPC drivers out in the wild?  Plus, it seems that it would
>  definitely be a good thing for the kernel source to be tested  on multiple
>  endians as early as possible in its development to ease porting later on.
>  
>     ~ Tristan Miller
>        (monocasa)
>   
Sorry for waiting until now to reply.

We definately could just go BE from the outset.  I've been pretty
conflicted about deciding one way or another, so my waffling will
probably show.  Maybe we should talk it out and make a firmer
decision.  Of course, we don't have a choice on 64-bit ppc, but
reactos doesn't have an amd64 port either, nor can it even be
built with 100% 64-bit tools, so I didn't think of it as much of a
deficiency.  BE has definate advantages, but I think I wouldn't 
keep pe-coff (at least in kernel land) if LE wasn't on the table.
BE elf tools make lots of things easier, but at the expense of 
making the driver loading parts arch-specific.

These are the reasons I decided to make reactos-ppc LE.  Although
maybe not the best reasons:

- ReactOS already loads LE PE-COFF everywhere, and PE-COFF tools 
  are generally LE.  NT is dug into PE-COFF pretty well.  As well,
  certain macros and data structures have implicit endianness 
  assumptions that would have to be sorted out.
- Some data structures are shared between kernel and userland 
  and those would have to appear swapped for an LE user program,
  if LE userland is supported.  The other alternative is not to
  support the few NT-PPC binaries that are out there.  Not a great
  functionality loss admittedly.
- It'd be desirable to support legacy userland programs even just
  for a brief wow before building something useful.

Of course, you point out good reasons for going BE:

- Tools that aren't a hack
- Easier debugging
- Easier migration to 64-bit ppc
- We don't need no stinkin' NTVDM :-)
- Get BE out of the way "early"

A BE ReactOS should probably convert away from PE-COFF as it's difficult
enough as things are to support it.  kjk wrote some elf code which could
be made to work for our purposes.  I've considered doing the same before
and I basically have a plan for emulating needed PE-COFF features from
elf. 

What do you think?
-- 
The way out is via the door. Why is it that no one will use this method? - Confucius