This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH, ARM] Low interrupt latency support (avoiding ldm/stm)
- From: Phil Blundell <philb at gnu dot org>
- To: Paul Brook <paul at codesourcery dot com>
- Cc: gcc-patches at gcc dot gnu dot org, Julian Brown <julian at codesourcery dot com>, rearnsha at arm dot com
- Date: Mon, 17 May 2010 13:06:19 +0100
- Subject: Re: [PATCH, ARM] Low interrupt latency support (avoiding ldm/stm)
- References: <20091127175025.7fb6ceae@rex.config> <20091127183049.79a0d201@rex.config> <20100426141632.586aed7e@rex.config> <201005171211.13307.paul@codesourcery.com>
On Mon, 2010-05-17 at 12:11 +0100, Paul Brook wrote:
> My understanding is that this option is only useful is only really useful
> useful on certain third party cores, none of which are supported by FSF gcc.
> I'd also guess that future (or even present) cores will have a different
> criteria for generating "low-latency" code.
I'm fairly sure that LDM and STM are uninterruptible instructions on
most/all current cores, both ARM's own and those from third parties. An
instruction like "stmia r0, {r0-r15}" will take at least 16 cycles on
most processors and interrupts are locked out for the duration.
To take a random-ish example, see the ARM9EJ-S reference manual:
http://infocenter.arm.com/help/topic/com.arm.doc.ddi0222b/CHDCBECF.html
So, if you can guarantee that no LDM/STM instructions will be executed,
it does give you a potentially significant improvement in worst-case
interrupt latency. Obviously this is only true in fairly specialised
software systems but I don't think the issue is restricted to third
party cores.
p.