Dominic Sweetman wrote:
> Jun Sun (firstname.lastname@example.org) writes:
> > The USB sub-system uses "unaligned.h" file to access unaligned data.
> > All the unaligned data access functions depend on "uld" and "usw"
> > instructions, which are not available on many CPUs.
> You won't find the instruction 'uld' in *any* MIPS CPU.
> uld is an assembler macro-instruction translating into a
> pair (the instructions are called load-double-left and
> load-double-right). The exact translation depends on whether you're
> running big-endian or little-endian... but the 32-bit version on a
> big-endian CPU is that
> ulw $1, <address>
> is assembled as
> lwl $1, <address>
> lwr $1, <address+3>
> The way that the load-left and load-right work together is kind of
> tricky to get your head round.
> So far as I know, all 64-bit MIPS CPUs implement ldl/ldr and the store
> equivalents. MIPS patented these instructions, so clones like Lexra's
> don't implement the 32-bit versions (lwl, lwr etc).
> Dominic Sweetman
> Algorithmics Ltd
> The Fruit Farm, Ely Road, Chittering, CAMBS CB5 9PH, ENGLAND
> phone: +44 1223 706200 / fax: +44 1223 706250 / http://www.algor.co.uk
Thanks for the clarification.
I looked at my problem again, and it turns out that it was caused by
"-mips2" compiler option. If I use "-mips3", the complain goes away,
which seems to make sense - assuming "uld" and "usw" are introduced in
This actually brings another question (which I thought I have posted
before). Take a look of arch/mips/Makefile, you will find most CPUS
uses -mips2 compiler option. While -mips2 is safe, it cannot take
advantages of "uld" etc. Is there any reason that we don't want to use
-mips3, at least for some of the later CPUs?
If we have to use "-mips2" option, is there a clean way which allows us
to "uld/usw" instructions (instead of manually twicking the compilation
for each file that uses them)?
Another question is that in the same file most CPUs will take another
compiler option such as "-mcpu=r8000", in which case the cpu model
usually does NOT correspond to the actual CPU. Why is that?