On Wed, Jan 14, 2004 at 05:11:07PM +0100, valvoline wrote:
of drivers are required? i think that simple win32-drivers cannot work
properly in a different architecture with different *endian.
totally irrelevent and off-topic, but ... the ppc can (or used
to be able to) switch endianess dynamically. To be more correct,
it can run some user-space code that was little endian, by having
the kernel set the appropriate bit in the MSR before it ran the
app. I have no idea is the linux kernel saves/restores this bit(s),
or if this is still supported on the newest processors.
--linas
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
On 15-jan-04, at 1:13, linas@austin.ibm.com wrote:
totally irrelevent and off-topic, but ... the ppc can (or used
to be able to) switch endianess dynamically. To be more correct,
it can run some user-space code that was little endian, by having
the kernel set the appropriate bit in the MSR before it ran the
app. I have no idea is the linux kernel saves/restores this bit(s),
or if this is still supported on the newest processors.
It can also run supervisor-level code in little endian mode.
The 2.0 PEM still doesn't show this support as optional [look at the
ILE and LE bits in the MSR], but it does say that "the code sequence
used to switch from big to little-endian mode may differ among
processors".
Also note that the 970 does not support wrong^H^H^H^H^Hlittle-endian
mode
at all.
As these bits are in the MSR, and you are supposed to leave alone the
bits
that you don't explicitly touch, I suppose the Linux kernel
saves/restores
the bits just fine. But I didn't check whether it actually does, so
YMMV.
Segher
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Gabriel Paubert <hidden> Date: 2004-01-15 11:50:23
On Thu, Jan 15, 2004 at 10:30:21AM +0100, Segher Boessenkool wrote:
On 15-jan-04, at 1:13, linas@austin.ibm.com wrote:
quoted
totally irrelevent and off-topic, but ... the ppc can (or used
to be able to) switch endianess dynamically. To be more correct,
it can run some user-space code that was little endian, by having
the kernel set the appropriate bit in the MSR before it ran the
app. I have no idea is the linux kernel saves/restores this bit(s),
or if this is still supported on the newest processors.
It can also run supervisor-level code in little endian mode.
The 2.0 PEM still doesn't show this support as optional [look at the
ILE and LE bits in the MSR], but it does say that "the code sequence
used to switch from big to little-endian mode may differ among
processors".
Also note that the 970 does not support wrong^H^H^H^H^Hlittle-endian
mode
at all.
BTW, where did you find this? IBM's sites have no real documentation on
the 970, or I was too dumb to find them.
As these bits are in the MSR, and you are supposed to leave alone the
bits
that you don't explicitly touch, I suppose the Linux kernel
saves/restores
the bits just fine. But I didn't check whether it actually does, so
YMMV.
It's more complex than this, because it is pseudo little endian, munging
low address bits. The memory seen as an array of bytes is not invariant
through this transformation for most processors. For example the character
chain "abcdefgh" copied from a kernel buffer through a read call will
look as "hgfedcba" from a little endian application. Bridges have a
"LE" bit to also mung addresses during DMA and PIO transfers.
But this makes it almost impossible to support a mixture of little and
bug endian applications. Indeed the ROM BIOS x86 emulator I wrote a
few years ago runs in big-endian mode and uses {l,st}[hw]brx instructions
to emulate x86 crapitecture.
Gabriel
P.S.: there is nothing wrong with calling little-endian wrong or
perverted or fucked-up ;-)
file (or written from the kernel
Also note that the 970 does not support wrong^H^H^H^H^Hlittle-endian
mode
at all.
BTW, where did you find this? IBM's sites have no real documentation on
the 970, or I was too dumb to find them.
I work for IBM. I did not realize this information wasn't
publicly available -- if it isn't, and it's not just you.
It's more complex than this, because it is pseudo little endian,
munging
low address bits.
It's not, afaics.
The memory seen as an array of bytes is not invariant
through this transformation for most processors. For example the
character
chain "abcdefgh" copied from a kernel buffer through a read call will
look as "hgfedcba" from a little endian application.
Representation depends on access size.
Bridges have a
"LE" bit to also mung addresses during DMA and PIO transfers.
Well yeah, PCI swizzling is awful and complicates the hell out
of everything.
But this makes it almost impossible to support a mixture of little and
bug endian applications. Indeed the ROM BIOS x86 emulator I wrote a
few years ago runs in big-endian mode and uses {l,st}[hw]brx
instructions
to emulate x86 crapitecture.
That's how to normally access PCI as well, yeah.
P.S.: there is nothing wrong with calling little-endian wrong or
perverted or fucked-up ;-)
I don't know if I trust you here -- you wrote "bug endian" just a few
lines up ;-)
Segher
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Sven Luther <hidden> Date: 2004-01-15 13:12:58
On Thu, Jan 15, 2004 at 02:00:16PM +0100, Segher Boessenkool wrote:
quoted
quoted
Also note that the 970 does not support wrong^H^H^H^H^Hlittle-endian
mode
at all.
BTW, where did you find this? IBM's sites have no real documentation on
the 970, or I was too dumb to find them.
I work for IBM. I did not realize this information wasn't
publicly available -- if it isn't, and it's not just you.
I think there was made mention of this in one of the more technical reports
that followed the G5 release.
Friendly,
Sven Luther
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
I think there was made mention of this in one of the more technical
reports
that followed the G5 release.
Yeah I figured I must have seen it somewhere before (phew, I'm saved
;-) ).
Segher
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Gabriel Paubert <hidden> Date: 2004-01-16 19:54:06
On Thu, Jan 15, 2004 at 02:00:16PM +0100, Segher Boessenkool wrote:
quoted
quoted
Also note that the 970 does not support wrong^H^H^H^H^Hlittle-endian
mode
at all.
BTW, where did you find this? IBM's sites have no real documentation on
the 970, or I was too dumb to find them.
I work for IBM. I did not realize this information wasn't
publicly available -- if it isn't, and it's not just you.
The fact is that the documentation for the 970 is by far the
poorest from all the processors on IBM's website. I believed
IBM would release more information about these processors. Or
doesn't IBM really want to sell them?
Anyway, since you seem to have ties inside IBM ;-), you might
know why they do not even give a list of differences of the
970 implementation. I know from another source that the 970 does
not have BATs, but supports large pages with a size of 16MB.
quoted
It's more complex than this, because it is pseudo little endian,
munging
low address bits.
It's not, afaics.
It's the case for all 603/604/7xx/7xxx processors.
quoted
The memory seen as an array of bytes is not invariant
through this transformation for most processors. For example the
character
chain "abcdefgh" copied from a kernel buffer through a read call will
look as "hgfedcba" from a little endian application.
Representation depends on access size.
Indeed, but I said array of bytes, implying byte size accesses even
if it was not clear. However, I forgot to mention that it should be
an 8 byte array on a 8 byte boundary. This is the rule for all the
processors I have mentioned before.
quoted
Bridges have a
"LE" bit to also mung addresses during DMA and PIO transfers.
Well yeah, PCI swizzling is awful and complicates the hell out
of everything.
Well, if the processors switched to little endian with byte
invariant addressing, there would be no need for mode switching
control bits in the bridges, and it would be almost easy to
support a mixture of BE and LE applications (note that I said
"almost", but the only practical interest is for emulators).
quoted
But this makes it almost impossible to support a mixture of little and
bug endian applications. Indeed the ROM BIOS x86 emulator I wrote a
few years ago runs in big-endian mode and uses {l,st}[hw]brx
instructions
to emulate x86 crapitecture.
That's how to normally access PCI as well, yeah.
quoted
P.S.: there is nothing wrong with calling little-endian wrong or
perverted or fucked-up ;-)
I don't know if I trust you here -- you wrote "bug endian" just a few
lines up ;-)
Damned laptop keyboards! U and I keys are just too close from each
other;-) Apart from this, if you look up some archives, you'll certainly
find that I think, live and breathe big-endianly ;-) (bit 0 is the most
significant bit, period)
Now the fact that the 970 does not support backwards-endian is a very
good thing. From time to time (although it has been less frequent
recently) somebody suggest on the list that Linux/PPC switches to the
dark side of the endianness. The fact that some processors don't support
it will be a killer argument.
Gabriel
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Benjamin Herrenschmidt <benh@kernel.crashing.org> Date: 2004-01-17 03:25:43
Anyway, since you seem to have ties inside IBM ;-), you might
know why they do not even give a list of differences of the
970 implementation. I know from another source that the 970 does
not have BATs, but supports large pages with a size of 16MB.
Yup, it's more/less a POWER4 in this regard (which is probably
as badly documented :)
I'll check out the status of public specs, I _think_ that there is
some doc in the process of beeing cleaned up & declassified for this
chip, but I'm not 100% sure at this point.
Now the fact that the 970 does not support backwards-endian is a very
good thing. From time to time (although it has been less frequent
recently) somebody suggest on the list that Linux/PPC switches to the
dark side of the endianness. The fact that some processors don't support
it will be a killer argument.
Hehe, you know, there isn't much risk that we take such a patch in
the first place anyway :)
Ben.
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
On Thu, Jan 15, 2004 at 02:00:16PM +0100, Segher Boessenkool wrote:
quoted
quoted
P.S.: there is nothing wrong with calling little-endian wrong or
perverted or fucked-up ;-)
I don't know if I trust you here -- you wrote "bug endian" just a few
lines up ;-)
Damned laptop keyboards! U and I keys are just too close from each
other;-) Apart from this, if you look up some archives, you'll certainly
find that I think, live and breathe big-endianly ;-) (bit 0 is the most
significant bit, period)
Although I prefer big endian myself, I don't like counting bits in the `wrong'
direction ;-) Hence bit 0 is always the least significant bit.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
Anyway, since you seem to have ties inside IBM ;-), you might
know why they do not even give a list of differences of the
970 implementation.
I guess the documentation is just not ready for public consumption.
I don't really know.
I know from another source that the 970 does
not have BATs, but supports large pages with a size of 16MB.
The BAT thing at least is documented (and has been documented
_for ever_ -- see the PEM, the 970 is a 64-bit chip. Get the
rev 2.0 PEM from the 970 doc page).
The large page thing is cpu specific afaik (from memory).
Segher
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Benjamin Herrenschmidt <benh@kernel.crashing.org> Date: 2004-01-19 22:05:58
The BAT thing at least is documented (and has been documented
_for ever_ -- see the PEM, the 970 is a 64-bit chip. Get the
rev 2.0 PEM from the 970 doc page).
The large page thing is cpu specific afaik (from memory).
On 19-jan-04, at 23:05, Benjamin Herrenschmidt wrote:
quoted
The BAT thing at least is documented (and has been documented
_for ever_ -- see the PEM, the 970 is a 64-bit chip. Get the
rev 2.0 PEM from the 970 doc page).
The large page thing is cpu specific afaik (from memory).
POWER3 had BATs
Sure, but BATs are not *required* by the 64-bit architecture.
Segher
p.s. Well actually, I went to check -- and the PEM 2.0 _does_
define BATs for 64-bit. Let's put this under "POWER4 and
derivatives specific" as well then, until the docs get fixed :-)
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Gabriel Paubert <hidden> Date: 2004-01-21 17:27:25
On Tue, Jan 20, 2004 at 07:01:15PM +0100, Segher Boessenkool wrote:
On 19-jan-04, at 23:05, Benjamin Herrenschmidt wrote:
quoted
quoted
The BAT thing at least is documented (and has been documented
_for ever_ -- see the PEM, the 970 is a 64-bit chip. Get the
rev 2.0 PEM from the 970 doc page).
The large page thing is cpu specific afaik (from memory).
POWER3 had BATs
Sure, but BATs are not *required* by the 64-bit architecture.
Segher
p.s. Well actually, I went to check -- and the PEM 2.0 _does_
define BATs for 64-bit. Let's put this under "POWER4 and
derivatives specific" as well then, until the docs get fixed :-)
Indeed, sorry for the late reply, but I was really wondering how you
could interpret a bit level description of the BATs and the sentences
describing them as "some implementations may not have them" ;-)
There are no mention of big/large/huge pages either[1], nor of
instructions which may have been added for Power4/970 (I know
about mfcrf)
Frankly speaking the current state of the documentation is worrying me,
I remember that when the PPC750 was announced, a lot of documentation
was added to IBM and Motorola websites in a matter of days.
Regards,
Gabriel
[1] well, I found some mentions of the large pages in a redbook about
Power4. But that's about all.
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/