search for: endianness

Hi Daniel, I know you only did a small change to support big/little endian reference outputs, but maybe you can help me. I'm running the test-suite on AArch64 and it's correctly detecting little-endian, even setting the ENDIAN=little on configure and Makefiles alike, but it still generates "big-endian" from Makefile.programs. Here's the first lines of: sandbox/test-...$

On Tue, Apr 21, 2015 at 06:22:20PM +0200, Greg Kurz wrote: > On Tue, 21 Apr 2015 16:06:33 +0200 > "Michael S. Tsirkin" <mst at redhat.com> wrote: > > > On Fri, Apr 10, 2015 at 12:20:21PM +0200, Greg Kurz wrote: > > > The VNET_LE flag was introduced to fix accesses to virtio 1.0 headers > > > that are always little-endian. It can also be used to

On Tue, Apr 21, 2015 at 06:22:20PM +0200, Greg Kurz wrote: > On Tue, 21 Apr 2015 16:06:33 +0200 > "Michael S. Tsirkin" <mst at redhat.com> wrote: > > > On Fri, Apr 10, 2015 at 12:20:21PM +0200, Greg Kurz wrote: > > > The VNET_LE flag was introduced to fix accesses to virtio 1.0 headers > > > that are always little-endian. It can also be used to

Hi, I'd like to use LLVM to compile and optimise code when I don't know whether the target CPU is big- or little-endian. This would allow me to create a single optimised LLVM bitcode binary of an application, and then run it through a JIT compiler on systems of differening endianness. I realise that in general the LLVM IR depends on various characteristics of the target; I'd just like to be able to remove this dependency for the specific case of unknown target endianness. Here's a sketch of how it would work: 1. Extend TargetData::isBigEndian() and LLVM bitcode's...

On Wed, Jan 13, 2016 at 06:09:41PM +0100, Greg Kurz wrote: > The default use case for vhost is when the host and the vring have the > same endianness (default native endianness). But there are cases where > they differ and vhost should byteswap when accessing the vring: > - the host is big endian and the vring comes from a virtio 1.0 device > which is always little endian > - the architecture is bi-endian and the vring comes from a...

On Wed, Jan 13, 2016 at 06:09:41PM +0100, Greg Kurz wrote: > The default use case for vhost is when the host and the vring have the > same endianness (default native endianness). But there are cases where > they differ and vhost should byteswap when accessing the vring: > - the host is big endian and the vring comes from a virtio 1.0 device > which is always little endian > - the architecture is bi-endian and the vring comes from a...

...rz wrote: > On Wed, 10 Feb 2016 13:21:22 +0200 > "Michael S. Tsirkin" <mst at redhat.com> wrote: > > > On Wed, Jan 13, 2016 at 06:09:41PM +0100, Greg Kurz wrote: > > > The default use case for vhost is when the host and the vring have the > > > same endianness (default native endianness). But there are cases where > > > they differ and vhost should byteswap when accessing the vring: > > > - the host is big endian and the vring comes from a virtio 1.0 device > > > which is always little endian > > > - the architecture...

...rz wrote: > On Wed, 10 Feb 2016 13:21:22 +0200 > "Michael S. Tsirkin" <mst at redhat.com> wrote: > > > On Wed, Jan 13, 2016 at 06:09:41PM +0100, Greg Kurz wrote: > > > The default use case for vhost is when the host and the vring have the > > > same endianness (default native endianness). But there are cases where > > > they differ and vhost should byteswap when accessing the vring: > > > - the host is big endian and the vring comes from a virtio 1.0 device > > > which is always little endian > > > - the architecture...

Hi, all, I have a question about encoding/decoding in big/little endian machines. I have a client running in an old PowerBook G4 with big-endian CPU, the audio stream is encoded then transmitted to a Mac Mini with little-endian CPU, and decoded in this Mac Mini. I am wondering the decoded stream is in big-endian or little-endian? What kind of necessary steps I need to process when I build the

...t; According to > http://refspecs.linuxfoundation.org/ELF/ppc64/PPC-elf64abi.html, > "The high-order double-precision value (the one that comes first in > storage) must have the larger magnitude." > > So the order of the two doubles in your fp128 is not affected by the > endianness; although each individual double is. > Well I'm still trying to understand the code base, so I may get this completely wrong, but here is my understanding: Looking at the comment of TargetLowering::hasBigEndianPartOrdering, it seems that, all "internal types" (e.g. ppc_fp128, i12...

Thanks for the answer. So data are stored in little-endian format on the WAVE file. But have I to encode in big endian format or little endian is ok?! Thanks ---------- Original Message ---------------------------------- From: "John Miles" <jmiles@pop.net> Date: Tue, 23 May 2006 12:15:05 -0700 >You are probably reading little-endian samples on a big-endian platform, and

Hi, all As I'm a Chinese, be patient of my poor description below. I compiled libgcc into llvm bitcode in both big endian and little endian. and got 2 different version of function: _ashldi3, the following is the fragment of this function: little endian: ============================================= ...... target datalayout =

Hi, > > static const uint32_t virtio_gpu_cursor_formats[] = { > > +#ifdef __BIG_ENDIAN > > + DRM_FORMAT_BGRA8888, > > +#else > > DRM_FORMAT_ARGB8888, > > +#endif > > DRM formats are supposed to be little endian, so this isn't really > correct. Well, maybe they where *intended* to be little endian at some point in the past. The actual code

Hi, > > static const uint32_t virtio_gpu_cursor_formats[] = { > > +#ifdef __BIG_ENDIAN > > + DRM_FORMAT_BGRA8888, > > +#else > > DRM_FORMAT_ARGB8888, > > +#endif > > DRM formats are supposed to be little endian, so this isn't really > correct. Well, maybe they where *intended* to be little endian at some point in the past. The actual code

Hello, Sam I used non-arm backend, and I used a target which likes mips has both big and little endianness. And I have ported llvm-gcc to this platform along with llvm backend. The issue is about IR endianness and how backend deal with the data and instructions in different endian, since I discovered 2 different IR generates the same asm code by llc for different endian target. > Message: 27 > D...

...names to the helpers that are involved in cross-endian support. Patch 2 is actually a v2 of the original patch. All devices now call a helper in the generic code, which DTRT according to vq->private_data, as suggested by Michael. --- Greg Kurz (2): vhost: helpers to enable/disable vring endianness vhost: disentangle vring endianness stuff from the core code drivers/vhost/net.c | 3 +++ drivers/vhost/scsi.c | 3 +++ drivers/vhost/test.c | 2 ++ drivers/vhost/vhost.c | 40 ++++++++++++++++++++++++++++------------ drivers/vhost/vhost.h | 1 + 5 files changed, 37 inser...

...names to the helpers that are involved in cross-endian support. Patch 2 is actually a v2 of the original patch. All devices now call a helper in the generic code, which DTRT according to vq->private_data, as suggested by Michael. --- Greg Kurz (2): vhost: helpers to enable/disable vring endianness vhost: disentangle vring endianness stuff from the core code drivers/vhost/net.c | 3 +++ drivers/vhost/scsi.c | 3 +++ drivers/vhost/test.c | 2 ++ drivers/vhost/vhost.c | 40 ++++++++++++++++++++++++++++------------ drivers/vhost/vhost.h | 1 + 5 files changed, 37 inser...

...his patch brings cross-endian support to vhost when used to implement > legacy virtio devices. Since it is a relatively rare situation, the > feature availability is controlled by a kernel config option (not set > by default). > > The vq->is_le boolean field is added to cache the endianness to be > used for ring accesses. It defaults to native endian, as expected > by legacy virtio devices. When the ring gets active, we force little > endian if the device is modern. When the ring is deactivated, we > revert to the native endian default. > > If cross-endian was compi...

...his patch brings cross-endian support to vhost when used to implement > legacy virtio devices. Since it is a relatively rare situation, the > feature availability is controlled by a kernel config option (not set > by default). > > The vq->is_le boolean field is added to cache the endianness to be > used for ring accesses. It defaults to native endian, as expected > by legacy virtio devices. When the ring gets active, we force little > endian if the device is modern. When the ring is deactivated, we > revert to the native endian default. > > If cross-endian was compi...

On Wed, 10 Feb 2016 13:21:22 +0200 "Michael S. Tsirkin" <mst at redhat.com> wrote: > On Wed, Jan 13, 2016 at 06:09:41PM +0100, Greg Kurz wrote: > > The default use case for vhost is when the host and the vring have the > > same endianness (default native endianness). But there are cases where > > they differ and vhost should byteswap when accessing the vring: > > - the host is big endian and the vring comes from a virtio 1.0 device > > which is always little endian > > - the architecture is bi-endian and th...