[fedora-arm] Fedora 20 for Raspberry Pi????

[Steve Underwood]

On 12/30/2013 07:41 PM, Gordan Bobic wrote:
> On 12/30/2013 10:08 AM, Steve Underwood wrote:
>> On 12/28/2013 12:27 AM, Gordan Bobic wrote:
>>> On 12/27/2013 04:02 PM, Richard W.M. Jones wrote:
>>>> On Fri, Dec 27, 2013 at 09:53:54AM +0000, Gordan Bobic wrote:
>>>>> How is transparent alignment fixup going to give you back the
>>>>> performance you lose from accesses straddling cache lines?
>>>>
>>>> You can have structs straddling cache lines and causing performance
>>>> problems without alignment issues, or structs being packed too close
>>>> together causing false sharing again w/o alignment being involved.
>>>>
>>>> If alignment problems cause performance issues, then we should deal
>>>> with those performance problems.  If they don't, we shouldn't worry
>>>> about them.
>>>>
>>>> Rich.
>>>>
>>>> ObHack: I once worked with an architecture [68k-based VME hardware]
>>>> that not only faulted on unaligned access, but also on accesses of the
>>>> wrong *size* (eg. using a short-sized read instruction instead of a
>>>> word-sized read instruction).  Dealing with that nonsense involved a
>>>> lot of compiler-specific massaging of code and some inline assembly 
>>>> ...
>>>
>>> I'm very glad you mentioned compilers - this is in fact easily fixable
>>> at compiler level. Intel's ICC has an option to make all arrays and
>>> structs always aligned to a boundary (up to 16 byte, IIRC). If GCC
>>> were to implement such a feature the problem could be made to go away
>>> without actually addressing the underlying cause of the problem. It
>>> might be a bodge, but since complete fix of the underlying problem
>>> isn't going to happen anyway, a good bodge would be a lot better than
>>> doing nothing.
>>>
>>> Gordan
>>>
>> How does this in any way related to the alignment problem? All C
>> compilers align arrays and structures in sensible ways by default. They
>> have to. Its a requirement of the C language. Problems come from things
>> like pointing directly at elements in  communication structures, which
>> may not be naturally aligned. They can also come from overriding the
>> default alignment of arrays and structures, which most compilers permit
>> these days, with a varierty of constructs like "#pragma pack(1)"
>
> It's related because char[] is byte aligned rather than word-aligned. 
> In some cases (e.g. e2fsprogs) a buffer is declared as char[4096], 
> which means that when it's cast into a struct, struct elements won't 
> be suitably aligned. If the compiler were to align all arrays to a 
> 16-byte boundary, this wouldn't be an issue.
>
> I accept that in some cases, having arrays and structures unaligned 
> may be useful (e.g. wire protocol packet parsing), but in most cases 
> it seems to be just lazy or uninformed programming. In those cases the 
> compiler aligning everything to a 16-byte boundary would help.
>
> Gordan
>
Do you know a compiler for anything that isn't really tiny (like an 8 
bit MCU) which doesn't align character arrays to start at a multiple of 
something meaningful (e.g. 4, 8, or 16)? It helps a lot with character 
0, but it doesn't help a whole lot with character 1.

I think its actually quite rare to find a misalignment problem that 
isn't related to working with multi-byte values in a buffer which is an 
image of something external, like a comms buffer or an image of 
something from disk.

Regards,
Steve