Hi,
I have a PCIE device attached to Broadcom XLP (MIPS) host processor.
The user space software gets access to the PCIE device registers address space
by doing ioctl on the PCIE device driver.
The XLP processor is in big endian mode. As PCIE is always in little endian mode,
when reading the PCIE device register (32-bits) from the software on XLP processor,
byte swapping should be needed after reading the register value. Similarly for when
writing to the device register.
But what I observe is that without byte swapping, things are working fine.
It's as if the XLP processor is acting in little endian mode when in fact it's in
big endian mode and the software is also big endian binary.

Any ideas for above behavior ?

Thank you.

A few.

I was in Electronic Hardware, and big/little endian affects comparatively little

When a databus is reading/writing a number twice it's size (32bit accessing 64bit, 16bit accessing 32 bit, or 8bit accessing 16bit) only then the endian thing is important. Every cpu since the Z80 and perhaps earlier can do a long read (8 bits doing a 16bit read. Where it can cause confusion is in the case of cpus with a half width bus - the 8088 (16bit internals, 8 bit databus) 68008 (same story) or the Celeron (same except wider).

But if you transfer for example, the number 0xABCDEF01 from disk, registers, or serial input to ram, and then transfer it back, it's still going to be 0xABCDEF01 . If it was 0x10FEDCBA, or 0xEF01ABCD, that CPU is not going to make much money for the manufacturer, is it? We don't have to worry about byte swapping. That's taken care of in CPU hardware design, at a lower level than Assembler. So AFAIK,if (on a 32bit cpu) you read in a 64bit number, the 8 bytes are read in 2 groups of 4. Big/little endian-ness only affects the order of these bytes traveling along the data bus.

The main time it matters is when looking at instruction set compatibility at Assembler level.

1 members found this post helpful.