Don't know if your version has this but: (From a post dated 2004) The latest version of the microblaze core in EDK6.2 SP1 (microblaze_v2_10_a) has optional support for a new pair of instructions:
msrset rd, IMM and msrclr rd, IMM this pair of instructions are basically an atomic test-and-set on the microblaze status register. We lobbied Xilinx to add these on the grounds of the code size reduction: mfs rd, rmsr andi rd, rd, ~2 mts rmsr, rd becomes msrclr r0, ~2 to clear interrupts, and similarly for enable interrupts (and caches too). Also you no longer need a scratch register when doing these manipulations on the MSR. Even better (well, in fact by design!), the msrclr instruction maps directly onto the very common save_flags_cli() macro, that is sprinkled liberally throughout the kernel and drivers. On Thu, Aug 6, 2009 at 9:51 AM, Jamie Lokier <ja...@shareable.org> wrote: > Michael Schnell wrote: > > > Let's assume you have a single CPU and no special atomic instructions. > > > > > > - Copy the trick used on ARM to implement atomic-compare-exchange > > > in the vsyscall page, without disabling interrupts. > > > > Modern ARM variants have "load-Link / Store-Conditional" instructions. > > Only quite recent ARMs. Not the ones I'm working yet :-) > > > NIOS does not have those and I don't suppose Microblaze has. > > With one CPU they're not really needed. > > > > The vsyscall trick is a good one, and works with/without MMU, and > > > with/without permission to disable interrupts in userspace. It's fast > > > too. I recommend reading the code. It's only a few instructions. > > > > I'll do so. > > > > Does the "vsyscall trick" not force a trap and thus Kernel interaction ? > > No, no trap. > > Also, ignore the bits in arch/arm/kernel/entry-armv.S which disable > the trick for noMMU. It's just because it needs to work at a > relocated address and nobody's implemented that. See also > kuser_cmpxchg_check (as opposed to .._fixup). That check doesn't work > on noMMU in general because of the different address space layout. > > -- Jamie > _______________________________________________ > uClinux-dev mailing list > uClinux-dev@uclinux.org > http://mailman.uclinux.org/mailman/listinfo/uclinux-dev > This message was resent by uclinux-dev@uclinux.org > To unsubscribe see: > http://mailman.uclinux.org/mailman/options/uclinux-dev >
_______________________________________________ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
