search for: littleendian

Hi all, Does anyone happen to know if there are *any* 32-bit architectures (on which Linux runs) for which the ABI for a "long long" is different from passing two "longs" in the appropriate order, i.e. (hi,lo) for bigendian or (lo,hi) for littleendian? I'd like to switch klibc to use the 64-bit file ABI thoughout, but it's a considerable porting effort, and I'm trying to figure out how to best manage it. -hpa

...ttached > > pretty version of the proposal in PDF format and pasted a 80-column safe text version > > below. > > > > A second smaller set could be: > > declare <type> @llvm.portable.load.<type>(<type>* ptr, i32 alignment, > > i1 host, i1 littleEndian, i1 atomic, i1 volatile, > > i1 nontemporal, i1 singlethread) > > > > declare void @llvm.portable.store.<type>(<type> data, <type>* ptr, > > i32 alignment, i1 host, i1 littleEndian, i1 atomic, i1 volatile, > > i1 nontemporal, i1 singlethread)...

Hi, As a first step to port the LLVM chain on an in-house big-endian processor, I'm integrating the native assembler as a new '-assemble -arch=' in llvm-mc. All work quite well, I have a correct output ELF format except that generated code is little-endian. I've understood that the endianess of the LLVM chain is controlled by the DataLayout class, but it appear to me that llvm-mc

--- hivex/hivexsh.pod | 9 ++++++++- 1 files changed, 8 insertions(+), 1 deletions(-) diff --git a/hivex/hivexsh.pod b/hivex/hivexsh.pod index 277e3ae..9336798 100644 --- a/hivex/hivexsh.pod +++ b/hivex/hivexsh.pod @@ -100,7 +100,14 @@ or even: Path elements (node names) are matched case insensitively, and characters like space, C<*>, and C<?> have I<no> special

Hi, i began to implement a common lookup function for SUSP and Rock Ridge entries: /* Obtain the payload bytes of all SUSP entries with a given signature. @param fs The data source from which to read CE blocks. @param dir_rec Memory containing the whole ISO 9660 directory record. @param sig Two characters of SUSP signature. E.g. "NM", "ER", ...

...rtable.store.E.<type>(<type> data, <type>* ptr, i32 alignment, i1 host, i1 atomic, i1 volatile, i1 nontemporal, i1 singlethread) // big endian store A second smaller set could be: declare <type> @llvm.portable.load.<type>(<type>* ptr, i32 alignment, i1 host, i1 littleEndian, i1 atomic, i1 volatile, i1 nontemporal, i1 singlethread) declare void @llvm.portable.store.<type>(<type> data, <type>* ptr, i32 alignment, i1 host, i1 littleEndian, i1 atomic, i1 volatile, i1 nontemporal, i1 singlethread) Valid values for type are scalar sizes i8, i16, i32,...

...ot about the arguments, but us related to the "tools:::foo". Where should I look next? It goes a bit beyond me to know where in R "tools:::foo" is being parsed. Guessing here - but might be related to the switch from 32-bit to 64-bit AND that PowerPC is BigEndian rather than LittleEndian? Could also be absolutely wrong, way off base, etc. --> shoot me down! Thanks, Michael

...but us related to the "tools:::foo". > > Where should I look next? It goes a bit beyond me to know where in R > "tools:::foo" is being parsed. > Guessing here - but might be related to the switch from 32-bit to > 64-bit AND that PowerPC is BigEndian rather than LittleEndian? Could > also be absolutely wrong, way off base, etc. --> shoot me down! > > Thanks, > Michael

I would like to know if it is possible to cross compile syslinux for a different architecture than the host (given a suitable toolchain)? I know currently the build system does not differentiate host and target as stated in build.mk . However I can see in the main Makefile the targets seem to be split into two groups: binary components and installer components. I was wondering if it were

Ok here's another one: player_example.c: In function `open_audio': player_example.c:138: `AFMT_S16_NE' undeclared (first use in this function) It worked fine once I switched it from _NE to _LE, this code will help portability: #if defined(__FreeBSD__) # define AFMT_S16_NE AFMT_S16_LE #elif defined(_AIX) || defined(AIX) # define AFMT_S16_NE AFMT_S16_BE #endif I'm not sure what

...arguments, but us related to the "tools:::foo". > > Where should I look next? It goes a bit beyond me to know where in R "tools:::foo" is being parsed. > Guessing here - but might be related to the switch from 32-bit to 64-bit AND that PowerPC is BigEndian rather than LittleEndian? Could also be absolutely wrong, way off base, etc. --> shoot me down! > > Thanks, > Michael > > ______________________________________________ > R-devel at r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel

Hi Steve, I don't know if syslinux is x86-only by design, or just by circumstance. Simply put, I like syslinux because it's simple and it works. I know that once I get it working, I can just edit a config file and put kernels/initrds in the right place. Grub2 is trash[1], and UEFI is awkward and uncomfortable to actually use - in that I have to currently have my kernel and initrd on

...the "tools:::foo". >> >> Where should I look next? It goes a bit beyond me to know where in R >> "tools:::foo" is being parsed. >> Guessing here - but might be related to the switch from 32-bit to >> 64-bit AND that PowerPC is BigEndian rather than LittleEndian? Could >> also be absolutely wrong, way off base, etc. --> shoot me down! >> >> Thanks, >> Michael > > ______________________________________________ > R-devel at r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel >

...o". >>> >>> Where should I look next? It goes a bit beyond me to know where in R >>> "tools:::foo" is being parsed. >>> Guessing here - but might be related to the switch from 32-bit to >>> 64-bit AND that PowerPC is BigEndian rather than LittleEndian? Could >>> also be absolutely wrong, way off base, etc. --> shoot me down! >>> >>> Thanks, >>> Michael >> >> ______________________________________________ >> R-devel at r-project.org mailing list >> https://stat.ethz.ch/mailman/listi...

...Packet.F = true; // boolean } The problem is this definition must be really platform independent: the same code must work identically on Cortex-M, ARM9 and MIPS, and north side (x86_64 primarily). So I need attributes supported by GCC6: __attribute__((packed)) for structures and __attribute__((big/littleendian)) for struct fields. As a variant, I'm going to write some special DDL scheme compiler alike ASN.1 compilers (with a human-readable syntax for 1C programmers). Looking on code generated by clang, it looks like LLVM IR not only has no support for endianness attributes but also has pure support...

...s that + /// Addrspace1 is a subset of Addrspace2. + virtual AddrspaceRelation getAddrspaceRelation( + int Addrspace1, + int Addrspace2) const { + return Equivalent; + } + + virtual ~AddrspacesDescriptor() {} +}; + class TargetData : public ImmutablePass { private: bool LittleEndian; ///< Defaults to false unsigned char PointerMemSize; ///< Pointer size in bytes unsigned char PointerABIAlign; ///< Pointer ABI alignment unsigned char PointerPrefAlign; ///< Pointer preferred alignment + const AddrspacesDescriptor &Addrspaces;...

...+ virtual AddrspaceRelation getAddrspaceRelation( > + int Addrspace1, > + int Addrspace2) const { > + return Equivalent; > + } > + > + virtual ~AddrspacesDescriptor() {} > +}; > + > class TargetData : public ImmutablePass { > private: > bool LittleEndian; ///< Defaults to false > unsigned char PointerMemSize; ///< Pointer size in bytes > unsigned char PointerABIAlign; ///< Pointer ABI alignment > unsigned char PointerPrefAlign; ///< Pointer preferred > alignment > + const AddrspacesDesc...

Hi Eli, Mon Ping, > In ISO/IEC WG14 n1169 on the C extensions to support embedded > processors, any two address spaces must be disjoint, must be > equivalent, or must be nested. Ah, that standard is a lot clearer on this subject than the DSP-C one I read was. > As Eli indicated, the actual relationship is platform specific depending on > what makes the most sense for

In ISO/IEC WG14 n1169 on the C extensions to support embedded processors, any two address spaces must be disjoint, must be equivalent, or must be nested. As Eli indicated, the actual relationship is platform specific depending on what makes the most sense for your hardware and how the program will behave will depend on that relationship. -- Mon Ping On Jul 17, 2008, at 7:25 AM, Eli

...ll --3135-- --show-leak-kinds=all --3135-- -v --3135-- Contents of /proc/version: --3135-- Linux version 3.10.0-327.10.1.el7.x86_64 (builder at kbuilder.dev.centos.org) (gcc version 4.8.3 20140911 (Red Hat 4.8.3-9) (GCC) ) #1 SMP Tue Feb 16 17:03:50 UTC 2016 --3135-- Arch and hwcaps: AMD64, LittleEndian, amd64-cx16-rdtscp-sse3-avx --3135-- Page sizes: currently 4096, max supported 4096 --3135-- Valgrind library directory: /usr/lib64/valgrind --3135-- Reading syms from /usr/local/bin/ping --3135-- object doesn't have a symbol table --3135-- Reading syms from /usr/lib64/ld-2.17.so --3135-- Re...