Re: mb-gcc producing incorrect code ???

On 2009-02-25, luudee <rudolf.usselmann@gmail.com> wrote:
> I know that MB is big-endian, vs my linux box being little-endian.
> But shouldn't the C compiler produce the same results, regardless
> of the system endianness ?

No, as far as I know, casting a pointer to int to a pointer to char
and accessing the data as chars is undefined. (I'm not sure, but I
don't think that the standard even guarantees that two's complement
numbers are used although this is probably a safe bet to make.)

If you want to do something like this in a more portable fashion, use
something like:

  int i = 0xaabbccdd;
  char a,b,c,d;
  a = i & 0xff;
  b = (i >> 8) & 0xff;
  c = (i >> 16) & 0xff;
  d = (i >> 24) & 0xff;

/Andreas

Here is a small test program:

int main() {
unsigned int    dword;
unsigned char   *c;

dword = 0x87654321;
c = (char *)&dword;

printf("%0x\n", dword);
printf("c[0]=%02x\n", c[0]);
printf("c[1]=%02x\n", c[1]);
printf("c[2]=%02x\n", c[2]);
printf("c[3]=%02x\n", c[3]);

return(0);
}


On Linux (i386), I get:

87654321
c[0]=21
c[1]=43
c[2]=65
c[3]=87

But on the Microblaze system, I get:

87654321
c[0]=87
c[1]=65
c[2]=43
c[3]=21

I know that MB is big-endian, vs my linux box being little-endian.
But shouldn't the C compiler produce the same results, regardless
of the system endianness ?

Cheers,
rudi

In article <1c3663ae-9616-416b-9a6f-d4d2d8143f76@r4g2000yqa.googlegroups.com>,
luudee  <rudolf.usselmann@gmail.com> wrote:

>I know that MB is big-endian, vs my linux box being little-endian.
>But shouldn't the C compiler produce the same results, regardless
>of the system endianness ?

Only if you stick to doing permitted things, and writing to an object
of one size and reading it via an pointer to an object of another size
is precisely one of the things that is forbidden.

If you want to read the parts of a dword in an endianness-independent fashion,
try

A = x&0xff;
B = (x>>8)&0xff;
C = (x>>16)&0xff;
D = (x>>24)&0xff;

Tom

>I know that MB is big-endian, vs my linux box being little-endian.
>But shouldn't the C compiler produce the same results, regardless
>of the system endianness ?

Which one is right?

If the compiler could do the "right" thing, we wouldn't have
endian wars.

-- 
These are my opinions, not necessarily my employer's.  I hate spam.

On Feb 25, 3:55=A0pm, Thomas Womack <twom...@chiark.greenend.org.uk>
wrote:
>
> Only if you stick to doing permitted things, and writing to an object
> of one size and reading it via an pointer to an object of another size
> is precisely one of the things that is forbidden.
>
..
>
> Tom

So what is considered "permitted" ?

How about:

union my_union {
	unsigned int dword[1];
	unsigned char byte[4];
};

I guess the bigger question here is how to correctly
interface a little endian peripheral to a big-endian
SoC ?

Byte swapping everything would mean that the user manual
for the pripoheral would have to be rewritten as well ...

Can I just place a mirror next to my monitor (at 45
degrees) and just work of that for this project ?


Cheers,
rudi

On Feb 25, 4:08=A0pm, hal-use...@ip-64-139-1-69.sjc.megapath.net (Hal
Murray) wrote:
> >I know that MB is big-endian, vs my linux box being little-endian.
> >But shouldn't the C compiler produce the same results, regardless
> >of the system endianness ?
>
> Which one is right?
>
> If the compiler could do the "right" thing, we wouldn't have
> endian wars.

Well, clearly the "right thing", imho, would be to be consistent.

rudi

On Wed, 25 Feb 2009 03:00:23 -0800 (PST), luudee <rudolf.usselmann@gmail.com>
wrote:

>On Feb 25, 4:08&#4294967295;pm, hal-use...@ip-64-139-1-69.sjc.megapath.net (Hal
>Murray) wrote:
>> >I know that MB is big-endian, vs my linux box being little-endian.
>> >But shouldn't the C compiler produce the same results, regardless
>> >of the system endianness ?
>>
>> Which one is right?
>>
>> If the compiler could do the "right" thing, we wouldn't have
>> endian wars.
>
>Well, clearly the "right thing", imho, would be to be consistent.

I think you'd need a better language than C for that.
Ada's representation clauses come to mind - YOU define the data layout,
exactly as the hardware does it.

But porting Gnat to microblaze is probably non-trivial. (There is supposedly a
PPC port, but I haven't heard of anyone using it with EDK)

Meanwhile, faking it with shifts and masks is likely to be the best bet for
portablility.

- Brian

>I guess the bigger question here is how to correctly
>interface a little endian peripheral to a big-endian
>SoC ?

It's a hard problem.  It's been around for ages.


>Byte swapping everything would mean that the user manual
>for the pripoheral would have to be rewritten as well ...

You may want byte swapping in the hardware.  It depends
on what you are talking to.  If it's something like a disk
or ethernet, where you often transfer text, you are probably
better off treating it as a byte stream which means you will
have to byte-swap (in software) to use things like 4 byte
integers.

Note that if you byte-swap the bus pins, that will
byte swap addresses on a shared bus.  So you may have
to swap addresses in the driver so they will come out
right when the hardware swaps them again.


You can probably write a user manual that covers both
cases.  The trick is to write it using words and word
addresses/offsets, then describe each word with
pictures and bit offsets or terms like "high byte"
rather than byte addresses.  "Word" in that sentence
means whatever the natural width of the bus is.

Or you can just describe it for the normal/natural case
and let the poor guy who is using it on the wrong-endian
system sort things out.  He should be familiar with the
problem and know how to read wrong-endian data sheets.

-- 
These are my opinions, not necessarily my employer's.  I hate spam.

On Feb 26, 3:24=A0am, hal-use...@ip-64-139-1-69.sjc.megapath.net (Hal
Murray) wrote:
> >I guess the bigger question here is how to correctly
> >interface a little endian peripheral to a big-endian
> >SoC ?
>
> It's a hard problem. =A0It's been around for ages.
>
> >Byte swapping everything would mean that the user manual
> >for the pripoheral would have to be rewritten as well ...
>
> You may want byte swapping in the hardware. =A0It depends
> on what you are talking to. =A0If it's something like a disk
> or ethernet, where you often transfer text, you are probably
> better off treating it as a byte stream which means you will
> have to byte-swap (in software) to use things like 4 byte
> integers.
>
> Note that if you byte-swap the bus pins, that will
> byte swap addresses on a shared bus. =A0So you may have
> to swap addresses in the driver so they will come out
> right when the hardware swaps them again.
>
> You can probably write a user manual that covers both
> cases. =A0The trick is to write it using words and word
> addresses/offsets, then describe each word with
> pictures and bit offsets or terms like "high byte"
> rather than byte addresses. =A0"Word" in that sentence
> means whatever the natural width of the bus is.
>
> Or you can just describe it for the normal/natural case
> and let the poor guy who is using it on the wrong-endian
> system sort things out. =A0He should be familiar with the
> problem and know how to read wrong-endian data sheets.
>
> --
> These are my opinions, not necessarily my employer's. =A0I hate spam.

Thanks for all the feedback guys !

Doing it software is not really feasible. I am working on a
new demo for our SATA II Host Controller for Virtex 5, and
was trying to implement the dosfs code that was pointed out
by Antti. Thats when I discovered that all the bytes where
reversed. It did not occur to me while I was writing the
sector read and write routines, as all data transfers where
done by DMA (on word boundaries).

So it really has to be byte swapped in hw to make it work
correctly.

Cheers,
rudi

On Feb 26, 7:55=A0pm, luudee <rudolf.usselm...@gmail.com> wrote:
> On Feb 26, 3:24=A0am, hal-use...@ip-64-139-1-69.sjc.megapath.net (Hal
>
>
>
> Murray) wrote:
> > >I guess the bigger question here is how to correctly
> > >interface a little endian peripheral to a big-endian
> > >SoC ?
>
> > It's a hard problem. =A0It's been around for ages.
>
> > >Byte swapping everything would mean that the user manual
> > >for the pripoheral would have to be rewritten as well ...
>
> > You may want byte swapping in the hardware. =A0It depends
> > on what you are talking to. =A0If it's something like a disk
> > or ethernet, where you often transfer text, you are probably
> > better off treating it as a byte stream which means you will
> > have to byte-swap (in software) to use things like 4 byte
> > integers.
>
> > Note that if you byte-swap the bus pins, that will
> > byte swap addresses on a shared bus. =A0So you may have
> > to swap addresses in the driver so they will come out
> > right when the hardware swaps them again.
>
> > You can probably write a user manual that covers both
> > cases. =A0The trick is to write it using words and word
> > addresses/offsets, then describe each word with
> > pictures and bit offsets or terms like "high byte"
> > rather than byte addresses. =A0"Word" in that sentence
> > means whatever the natural width of the bus is.
>
> > Or you can just describe it for the normal/natural case
> > and let the poor guy who is using it on the wrong-endian
> > system sort things out. =A0He should be familiar with the
> > problem and know how to read wrong-endian data sheets.
>
> > --
> > These are my opinions, not necessarily my employer's. =A0I hate spam.
>
> Thanks for all the feedback guys !
>
> Doing it software is not really feasible. I am working on a
> new demo for our SATA II Host Controller for Virtex 5, and
> was trying to implement the dosfs code that was pointed out
> by Antti. Thats when I discovered that all the bytes where
> reversed. It did not occur to me while I was writing the
> sector read and write routines, as all data transfers where
> done by DMA (on word boundaries).
>
> So it really has to be byte swapped in hw to make it work
> correctly.
>
> Cheers,
> rudi

if you did use 32 bit DMA transfer to DOS file buffer
then yes it would appear as all wrong

but, well microblaze is WRONG endian it just makes
lots of trouble

least significant byte of a word is at byte offset +3 :(
but this is what normally is read as first byte from
byte wide streaming interface, also from disk file
system.

on MB system your DMA should but te FIRST
byte as bits 31.24
then it should be ok

you probably need ad some parameter to swap
bytes into normal order or not depening the
endianess, doing it in software is not feasible

the same problem happens all around, USB, ethernet packets
need adjust the byte order many times to get it right.

i think there was lots of trouble with some early microblaze
linux usb drivers, when those did work then the usb
based ethernet adapters did not work, wanted own endian swap..



Antti