search for: endianizing

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

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 > -

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 > -

On Wed, Feb 10, 2016 at 01:11:34PM +0100, Greg Kurz 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

On Wed, Feb 10, 2016 at 01:11:34PM +0100, Greg Kurz 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

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

On Mon, Nov 30, 2015 at 7:24 PM Gao, Yunzhong < yunzhong_gao at playstation.sony.com> wrote: > 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

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

This series is a respin of the following patch: http://patchwork.ozlabs.org/patch/565921/ Patch 1 is preliminary work: it gives better 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):

This series is a respin of the following patch: http://patchwork.ozlabs.org/patch/565921/ Patch 1 is preliminary work: it gives better 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):

On Fri, 10 Apr 2015 12:19:16 +0200 Greg Kurz <gkurz at linux.vnet.ibm.com> wrote: > This 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

On Fri, 10 Apr 2015 12:19:16 +0200 Greg Kurz <gkurz at linux.vnet.ibm.com> wrote: > This 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

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: