General claim is modern systems have better branch predictors and compilers are much more advanced so their cost on instruction encoding space is not justified. This is from ARMv8 Instruction Set Overview The A64 instruction set does not include the concept of predicated or conditional execution. Benchmarking shows that modern branch predictors work well enough … Read more
I would assume that it’s indicating packages compiled for little-endian and hard-float ABI as appropriate – i.e. it’s a software thing and only tangentially related to the hardware. In other words, you don’t actually have an “armv7l” processor – you have an ARMv7 processor which may well have a hardware FPU (and can run big-endian … Read more
OK, the situation is more confusing than one would like. So, in an effort to clarify, here are the findings on this journey : accessing unaligned memory The only portable C standard solution to access unaligned memory is the memcpy one. I was hoping to get another one through this question, but apparently it’s the … Read more
http://infocenter.arm.com/help/topic/com.arm.doc.prd29-genc-009492c/index.html is a pretty good introductory document that gives an overview of something a little bit too complex to be satisfactorily explained by typing into a text box. But I’ll try to answer your direct questions below. It refers to an additional privilege option orthogonal to the execution modes. Secure world has the ability to … Read more
Main differences: ARM is a RISC style architecture – instructions have a regular size (32-bit for standard ARM and 16-bits for Thumb mode, though Thumb has some instructions that chew up 2 instruction ‘slots’) up through at least ARM v5 architecture (I’m not sure what v6 does), the interrupt model on ARM is vastly different … Read more
Instruction fetches can be done in chunks with the assumption that much of the time you are going to run through many instructions in a row. so instruction fetches can be more efficient, there is likely a handful or more clocks of overhead per transaction then the delay for the memory to have the data … Read more
In order to to get stacktrace of code which caused SIGSEGV instead of stacktrace of the signal handler, you have to get ARM registers from ucontext_t and use them for unwinding. But it is hard to do with _Unwind_Backtrace(). Thus, if you use libc++ (LLVM STL) and compile for 32-bit ARM, better try precompiled libunwind, … Read more
Yes Dalvik makes Jazelle useless. The only question is was Jazelle useful to begin with or is it 90% marketing hype? A good JIT or AOT(ahead of Time) compiler tends to give much better performance than trying to use specialized instructions. The register based approach of Dalvik might be faster than a traditional java bytecode … Read more
The ARM world is a bit messy. For the C programmers, things are simple: all ARM architectures offer a regular, 32-bit with flat addressing programming model. As long as you stay with C source code, the only difference you may see is about endianness and performance. Most ARM processors (even old models) can be both … Read more
The other possibility i can think of is: 1.Your process is running more than one thread. For eg – 2 say x & y. 2.Thread y hits the break point but you have attached gdb to thread x. This case is a Trace/breakpoint trap.