powerpc

I'm working on a PowerPC machine with in-core crypto. I'm having trouble porting AES key expansion from big endian to little endian using built-ins. Big endian works, but little endian does not. The algorithm below is the snippet presented in an IBM blog article . I think I have the issue isolated to line 2 below: typedef __vector unsigned char uint8x16_p8; uint8x64_p8 r0 = {0}; r3 = vec_perm(r1, r1, r5); /* line 1 */ r6 = vec_sld(r0, r1, 12); /* line 2 */ r3 = vcipherlast(r3, r4); /* line 3 */ r1 = vec_xor(r1, r6); /* line 4 */ r6 = vec_sld(r0, r6, 12); /* line 5 */ r1 = vec_xor(r1, r6); /*

I hope to find some help even if this issue might be more hardware than software related (we'll see). I'm working on a custom board based on Freescales P1021 processor (ppc, e500v2 core). A external PCB will be connected and could be configured by SPI. The specifications of this external PCB reads as it expects a 2-byte command in full duplex mode and that only the last byte is used to transfer data back on MISO. Knowing this i currently work to prepare some pieces of software to test this device. So I started with the well known spi_test program. root@p1021rdb:~# ./spi_test -D /dev

I am using ldd to show the dynamic library on Fedora/x86, and it shows different results each time it is used. Is that expected? Or is there an explanation? I remember it shows a fixed result on PPC/Linux. `ldd /bin/ls linux-gate.so.1 => (0x00e5b000) librt.so.1 => /lib/librt.so.1 (0x00c0c000) libselinux.so.1 => /lib/libselinux.so.1 (0x0095d000) libcap.so.2 => /lib/libcap.so.2 (0x00110000) libacl.so.1 => /lib/libacl.so.1 (0x00331000) libc.so.6 => /lib/libc.so.6 (0x00115000) libpthread.so.0 => /lib/libpthread.so.0 (0x00bc9000) /lib/ld-linux.so.2 (0x009d2000) libdl.so.2 => /lib/libdl.so.2

I'm trying to install devtools in a PowerPC with a R version 3.1.1 but failed at the end because the curl library: ... ** testing if installed package can be loaded Error in dyn.load(file, DLLpath = DLLpath, ...) : unable to load shared object '/path to/R/powerpc-unknown-linux-gnu-library/3.1/curl/libs/curl.so': /path to/R/powerpc-unknown-linux-gnu-library/3.1/curl/libs/curl.so: undefined symbol: BSWAP_32 Error: loading failed Execution halted ERROR: loading failed * removing ‘/path to/R/powerpc-unknown-linux-gnu-library/3.1/curl’ ERROR: dependency ‘curl’ is not available for package ‘httr’ *

I'm programming an embedded powerpc 32 system with a 32 kbyte 8-way set associative L2 instruction cache. To avoid cache thrashing we align functions in a way such that the text of a set of functions called at a high frequency (think interrupt code) ends up in separate cache sets. We do this by inserting dummy functions as needed, e.g. void high_freq1(void) { ... } void dummy(void) { __asm__(/* Silly opcodes to fill ~100 to ~1000 bytes of text segment */); } void high_freq2(void) { ... } This strikes me as ugly and suboptimal. What I'd like to do is avoid __asm__ entirely and use pure C89

I'm using gdb 7.4.1 on embedded powerpc target to perform some analysis on my multi-threaded C++ program that uses pthreads. My end goal is to script gdb with python to automate some common analysis functions. The problem is that I am finding some discrepancy in behavior when I run commands individually vs. in a gdb user-defined command (or invoking the same commands via python script). edit: I found this reference to a very similar problem on the main gdb mailing list. Although I don't completely follow Pedro's response about the limitation of async mode, I think he's implying that in async

I use Node.js for several jobs on my web apps and so far everthing's ok. But the Node.js uses Google's V8 as the default Javascript engine (JSE) and V8 runs exlusively on the x86 and ARM Instruction Set Architectures (ISA). Now I have a PPC processor Mac computer on which I want to run the Node.js . To do that, I'm adviced to use the Rhino + OpenJDK Shark Virtual Machine + Low Level Virtual Machine ( LLVM ) as the JIT compiler. Currently, that looks like the most applicable way of running Node.js on the PPC ISA. Or, is there a better way to do it? Could you tell beforehand if it would be

I'm currently trying to build a configuration to test some code on Big-Endian systems. Through chats and research, i've been convinced that a good target for these tests would be the PowerPC architecture. Since i don't own one, and don't expect to get direct access to one anytime soon, i'm looking for some kind of emulation software to test my code. Problem is, i've found no "easy to use" solution in this area. It seems there are at least 2 possibles solutions, one using QEMU, and the other one using PearPC. None of them is really easy to deploy. The way i see it : I would like something as