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

[Gordan Bobic]

On 12/30/2013 11:56 AM, Steve Underwood wrote:
> 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.

GCC 4.4.x didn't seem to, otherwise some of the errors I was looking at 
wouldn't have come up. malloc() seems to allocate 4-byte aligned on ARM, 
but char[] seems to be byte aligned.

Gordan