구차니의 잡동사니 모음

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 interpreter but if the difference in minor between that of an interpreter and that of a JIT. Hopefully one of the next versions of Android has a JIT.

It takes ~5-10 years to write a good virtual machine with state of the art garbage collectors and optimizers. Sun (and Microsoft) have spent those years. Google hasn't. Hopefully they will keep investing in it so that one day Android Java code isn't a 90% slower than it should be.

[링크 : http://stackoverflow.com/questions/1153076/does-android-castrate-the-arms-jazelle-technology] 

There are (at least) 4 different ways of executing Java:

1. interpretation

2. direct hardware execution

3. JIT compilation

4. AOT compilation

In order to answer your question of whether an ARM core with Jazelle

would improve performance you first need to state what you are

currently using, which core and what speed. If you use an interpreter,

anything will give a good speedup.

Note there are 2 versions of Jazelle: DBX which executes byte codes

directly (various ARM9's and all ARM11's support this). This gives

around 4x speedup over interpretation and has no memory or startup

overheads. There is also an optimizer which can improve performance

at runtime. However rather than generating native instructions like a

JIT, it optimizes the bytecode itself.

Jazelle-RCT supports either JIT or AOT compilation into the Thumb-2EE

instruction set (Cortex-A8/Cortex-A9). This gives near native performance

but when using a JIT you get the usual startup and memory overheads

(although far less than when using x86 due to ARM's better code density).

[링크 : http://www.embeddedrelated.com/showthread/comp.arch.embedded/109371-1.php] 

sudo apt-get install gettext libgtk2.0-dev rpm bison m4 libfreetype6-dev

sudo apt-get install libdbus-glib-1-dev liborbit2-dev intltool

sudo apt-get install ccache ncurses-dev zlib1g zlib1g-dev gcc g++ libtool

sudo apt-get install uuid-dev liblzo2-dev

sudo apt-get install tcl dpkg

sudo apt-get install texinfo

sudo apt-get install texlive

[링크 : http://forum.falinux.com/zbxe/index.php?document_srl=785246&mid=lecture_tip]

       -m, --compression-mode=MODE

              Set  the  default compression mode. The default mode is priority

              which tries the compressors in a predefinied order  and  chooses

              the  first successful one. The alternatives are: none (mkfs will

              not compress) and size (mkfs will try all compressor and chooses

              the one which have the smallest result).

       -x, --disable-compressor=NAME

              Disable  a  compressor.  Use  -L to see the list of the avaiable

              compressors and their default states.

       -X, --enable-compressor=NAME

              Enable a compressor. Use -L to see  the  list  of  the  avaiable

              compressors and their default states.

       -y, --compressor-priority=PRIORITY:NAME

              Set  the priority of a compressor. Use -L to see the list of the

              avaiable compressors and their default priority.  Priorities are

              used by priority compression mode.

       -L, --list-compressors

              Show the list of the avaiable compressors and their states.

       -t, --test-compression

              Call  decompress  after  every compress - and compare the result

              with the original data -, and some other check.

[링크 : http://manpages.ubuntu.com/manpages/saucy/man1/mkfs.jffs2.1.html] 

Timer-based delays

In 2012, ARM contributed a new udelay implementation allowing the system timer built into many ARMv7 CPUs to be used instead of a busy-wait loop.[8] Timer based delays are more robust on systems that use frequency scaling to dynamically adjust the processor's speed at runtime, as loops_per_jiffies values may not necessarily scale linearly. Also, since the timer frequency is known in advance, no calibration is needed at boot time.

One side effect of this change is that the BogoMIPS value will reflect the timer frequency, not the CPU's core frequency. Typically the timer frequency is much lower than the processor's maximum frequency, and some users may be surprised to see an unusually low BogoMIPS value when comparing against systems that use traditional busy-wait loops.

[링크 : http://en.wikipedia.org/wiki/BogoMips] 

ARM: 7452/1: delay: allow timer-based delay implementation to be selected

This patch allows a timer-based delay implementation to be selected by

switching the delay routines over to use get_cycles, which is

implemented in terms of read_current_timer. This further allows us to

skip the loop calibration and have a consistent delay function in the

face of core frequency scaling.

To avoid the pain of dealing with memory-mapped counters, this

implementation uses the co-processor interface to the architected timers

when they are available. The previous loop-based implementation is

kept around for CPUs without the architected timers and we retain both

the maximum delay (2ms) and the corresponding conversion factors for

determining the number of loops required for a given interval. Since the

indirection of the timer routines will only work when called from C,

the sa1100 sleep routines are modified to branch to the loop-based delay

functions directly.

[링크 : https://git.kernel.org/.../linux.git/commit/?id=d0a533b18235d36206b9b422efadb7cee444dfdb] 

Soft

• Full software floating point - compiler should refuse to generate a real FPU instruction and -mfpu= is ignored.
• FPU operations are emulated by the compiler
• Function calls are generated to pass FP arguments (float, double) in integer registers (one for float, a pair of registers for double)

Softfp

• To reiterate, function calls are generated to pass FP arguments in integer registers
• Compiler can make smart choices about when and if it generates emulated or real FPU instructions depending on chosen FPU type (-mfpu=)
• This means soft and softfp code can be intermixed

Hardfp

• Full hardware floating point.
• FP arguments are passed directly in FPU registers
• Cannot possibly run without the FPU defined in -mfpu= (or a superset of the FPU defined, where relevant)
• FPU instructions could be emulated by the kernel so that FPU-less systems could run with this ABI but as far as we know this does not exist
• No function prologue or epilogue requirements for FP arguments, no pipeline stalls, maximum performance (just like in PowerPC and MIPS)

[링크 : https://wiki.debian.org/ArmHardFloatPort/VfpComparison]