lkml.org 
[lkml]   [2011]   [Feb]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: ARM unaligned MMIO access with attribute((packed))
Date
Arnd Bergmann <arnd@arndb.de> writes:

> On Wednesday 02 February 2011 17:37:02 Russell King - ARM Linux wrote:
>> We used to use inline assembly at one point, but that got chucked out.
>> The problem is that using asm() for this causes GCC to generate horrid
>> code.
>>
>> 1. there's no way to tell GCC that the inline assembly is a load
>> instruction and therefore it needs to schedule the following
>> instructions appropriately.
>>
>> 2. GCC will needlessly reload pointers from structures and other such
>> behaviour because it can't be told clearly what the inline assembly
>> is doing, so the inline asm needs to have a "memory" clobber.
>>
>> 3. It seems to misses out using the pre-index addressing, prefering to
>> create add/sub instructions prior to each inline assembly load/store.
>>
>> 4. There are no (documented) constraints in GCC to allow you to represent
>> the offset format for the half-word instructions.
>>
>> Overall, it means greater register pressure, more instructions, larger
>> functions, greater instruction cache pressure, etc.
>
> Another solution would be to declare the readl function extern and define
> it out of line, but I assume that this would be at least as bad as an
> inline assembly for all the points you brought up, right?
>
> Would it be possible to add the proper constraints for defining readl
> in an efficient way to a future version of gcc? That wouldn't help us
> in the near future, but we could at some points use those in a number
> of places.

I think it would be quite difficult to implement item 1 above in a way
that was actually usable. It would require some way to describe the
scheduling requirements of an asm. But the details of scheduling are
backend specific. Internally there are define_insn_reservation
structures which have names, but the names are processor specific which
is not what you want in source code (by processor specific I mean
specific to particular CPUs within a family). There are define_cpu_unit
structures which also have names, but are again processor specific.
What you want here is some non-processor-specific way to describe the
characteristics of an instruction. gcc does not have that today.

Even if somebody implemented all that, most inline asms are not a single
instructions and thus would find it difficult to take advantage of it.
I don't see this as paying off in the long run.

A more likely payoff would be to develop builtin functions for whatever
functionality is required that can not expressed in source code.

Item 2 above can be done. It is possible to describe precisely which
areas of memory are clobbered.

Item 3 above seems impossible to me. There is no way to combine
compiler generated instructions with user written inline asm such that
pre-index addressing can be used. Perhaps I misunderstand.

Item 4 can be implemented; please consider opening a feature request in
bugzilla.

Ian


\
 
 \ /
  Last update: 2011-02-02 20:17    [W:0.109 / U:78.888 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site