>> And on true 64 platforms it will be counterintuitive definition.
>>
>
> I don't know what you mean by this. What is a "true 64 platform", and
> what does that have to do with endianness?
As there was no context in the message, the Daniel's definiton gives
no sense for 64bit data as well as 16bit data.
>
> BTW, the context is that Daniel was looking at the multiboot2 draft,
> which specifies that some data be in "native endianness". I've objected
> that this is too vague.
>
> -Hollis
Looking at the draft - the objection is for CPU's that can use both endians.
But I thing they cannot use them concurently, but they have to do some
'switch' between the two modes. If not, there are two instruction sets,
and that I found less problematic.
Maybe Daniel mean:
Native endian depends on current CPU mode. If the CPU mode causes endian
mismatch (i.e. reads "the other" magic number) it means that the kernel
cannot be run in this mode. It is up to user or loader to do the mode
switch to run the kernel. I mean, we can have clever loader on such CPU's
that does mode-switch or we can have clever kernel with two multiboot
headers, each for one endian, one of them pointing to endian-switch code.
But I cannot read this in his message.
Btw. I also remember few CPU's with mixed endian. 32-bit read of
0x01 0x02 0x03 0x04 returns: 0x02010403.
--
Tomas Ebenlendr
http://drak.ucw.cz/ebik
_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
