[Top] [All Lists]

Re: load_unaligned() and "uld" instruction

To: Jun Sun <>
Subject: Re: load_unaligned() and "uld" instruction
From: Ralf Baechle <>
Date: Fri, 6 Oct 2000 18:28:21 +0200
Cc: "Kevin D. Kissell" <>,,, Dominic Sweetman <>
In-reply-to: <>; from on Thu, Oct 05, 2000 at 09:32:41PM -0700
References: <> <> <> <000d01c02782$32d31560$0deca8c0@Ulysses> <> <> <> <00d101c02f04$3a6d7340$0deca8c0@Ulysses> <>
On Thu, Oct 05, 2000 at 09:32:41PM -0700, Jun Sun wrote:

> > > > > Ralf, before the perfect solution is found, the following patch makes
> > > > > the gcc complain go away.  It just use ".set mips3" pragma.
> > 
> > Which, as Ralf correctly observes, will generate code that will
> > crash on 32-bit CPUs, 
> Why will it crash 32-bit CPUs?  On my R5432 CPU, the lwl/lwr sequence
> executes just fine.

That's a 64-bit CPU with a 32-bit bus ...

> Or do you mean it will crash SOME 32-bit CPUs?  Do those 32-bit CPUs
> support lwl or lwr?  If they don't, they should generate a reserved
> instruction exception.  If they do, I don't see any problem. 

It will crash all 32-bit CPUs.

> Not entirely.  I was thinking if the unaligned load/store instruction
> corrupts the upper 32 bit content on SOME cpus, maybe we do need to cut
> the upper 32bit as a workaround.  Well, I hope it is not necessary.

No, it happens on all CPUs.  Interrupts only restore the lower 32-bit of
the registers.  Partially this happens for the sake of compatibility with
32-bit cpus, partially it's also the because otherwise 8kb kernel stack
wouldn't be sufficient, we'd have to go up to 16kb stacks which again
has potencial influence on the memory managment that can reduce the
reliability of the kernel when low on memory, it increases the overhead.
In short unless a system has serious needs for 64-bit supporting 64-bit
is quite a loss.


<Prev in Thread] Current Thread [Next in Thread>