Re: xorg broken on Beaglebone black revision 300438 [some armv7 instructions do not match new kernel code?]

It may be that the following just means that more would have to be described to be complete about the expectations for the usage-context for the new alignment code in the kernel. But I ask anyway. It appears to me that the following code in the 11.0-CURRENT -r300701 check in: > +#if __ARM_ARCH

Re: xorg broken on Beaglebone black revision 300438 [some armv7 instructions do not match new kernel code?]

[I'm just fixing some typos that I've noticed and adding a couple of short notes for ease of interpretation.] On 2016-May-26, at 9:59 AM, Mark Millard wrote: > It may be that the following just means that more would have to be described > to be complete about the expectations for the usage-con

Are there SPARC [or other] aligned memory access requirements to avoid exceptions? [now that 11.0's armv6/v7 is allowing more unaligned accesses]

Is is safe to interpret that an rpi2 armv7/cortex-a7 unaligned access failure [from before -r300694] would (likely?) also be a failure on some forms of FreeBSD SPARC use? Why I ask: One of the ports that I had submitted a bug report for unaligned access problems on a rpi2 (armv7-a/cortex-a7 s

11.0-CURRENT -r300770 libc++ update vs. lang/powerpc64-xtoolchain-gcc: no go [self hosted powerpc64 context]

I do buildworld/buildkernel on a powerpc64 targeting itself via lang/powerpc64-xtoolchain-gcc (a.k.a. lang/powerpc64-gcc for the most part). [Getting that lang/powerpc64-gcc installed for self-hosted use does take some work-around activity.] I have buildworld build clang (but not use it). [I've

Re: Are there SPARC [or other] aligned memory access requirements to avoid exceptions? [now that 11.0's armv6/v7 is allowing more unaligned accesses]

All pure RISC implementations enforce 'natural alignment' - a 32bit data type must be aligned 32bit, i.e. 4 bytes, a 64bit data type must be 8 byte aligned, a 128bit data type must be 16 byte aligned. Some RISC implementations are not pure, but still the misalignment comes with a (performance) pena

Re: Are there SPARC [or other] aligned memory access requirements to avoid exceptions? [now that 11.0's armv6/v7 is allowing more unaligned accesses]

On 2016-May-26, at 8:21 PM, Cedric Blancher wrote: > All pure RISC implementations enforce 'natural alignment' - a 32bit > data type must be aligned 32bit, i.e. 4 bytes, a 64bit data type must > be 8 byte aligned, a 128bit data type must be 16 byte aligned. > Some RISC implementations are not pur

Re: Are there SPARC [or other] aligned memory access requirements to avoid exceptions? [now that 11.0's armv6/v7 is allowing more unaligned accesses]

SPARCv7, SPARCv8 and SPARCv9 mandate natural alignment like all 'normal' RISC implementations. SPARCv9 ABI adds some 'special' instructions (separate from the normal load/store instructions) for unaligned access, but as said they come with costs, as stated before PLUS the risk that they are unimple