From mboxrd@z Thu Jan 1 00:00:00 1970 From: linux@armlinux.org.uk (Russell King - ARM Linux) Date: Thu, 4 Aug 2016 13:16:19 +0100 Subject: [PATCH 1/8] ARM: assembler: introduce adr_l, ldr_l and str_l macros In-Reply-To: <20160804112229.GG7147@e103592.cambridge.arm.com> References: <1470238730-30038-1-git-send-email-ard.biesheuvel@linaro.org> <1470238730-30038-2-git-send-email-ard.biesheuvel@linaro.org> <20160803164940.GC7147@e103592.cambridge.arm.com> <20160804094451.GE7147@e103592.cambridge.arm.com> <20160804112229.GG7147@e103592.cambridge.arm.com> Message-ID: <20160804121619.GS1041@n2100.armlinux.org.uk> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Thu, Aug 04, 2016 at 12:22:29PM +0100, Dave Martin wrote: > The more conventional literal-.long approach could still be macro-ised > along the same lines, which might make the affected code more readable, > but the idiom you'd be replacing is well-understood and not very common. I don't see how it could be. You can't efficiently place the literal data alongside the instructions dealing with it. The only alternative is to use ldr rd, =foo, but that gets very stupid when you want to calculate the relative offset, and you end up with something like this for every relative load: ldr rd, =. sub rd, rd, #. - 4 ldr r1, =foo add r1, r1, rd As I've already said, I prefer the existing solution. It works, it's been known to work for the last 22 years. If it isn't broken, don't try to fix it. -- RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net.