1. vector?
1. development in i722
2. gogogo
3. vector state load/store elimination successfully!
4. need to clean up!
5. Need to implement NEON guest instructions
2. arm host?
1. need more time 
2. development at haru

1. partial behavior?
1. why no effect? why good? why bad?
2. seems no burst anymore; do research
3. do it now 2011-11-21 14:46
4. it seems partial inlining is failed.
1. astar is good
2. hmmer is extremely  bad! It is true!
3. need to know which functions are partial inlined and see why it performs bad!!
4. somehow, it degrade to trace mode. Run mostly in trace but not in functions.
5. side exit? NO! it's a stupid bug that I forgot link "RETURN" back to the procedure
1. using stack to find call path
6. but we can find early exit in other benchmarks, such as perlbench.
5. NEED to re-run ARM benchmarks
2. debug tonto - segfault, should be easy to fix
1. 11:28
2. done!!!
3. Sometimes it is difficult to say it's easy! when 
4. No! don't open stupid tab in browser!

Experiments

• i722 run NET Trace baseline, with workers 1 2 3, for x86 guest ISA
• i722 run NET Trace baseline with workers 12 3, for arm guest ISA
• 
  

TODO

1. remove unnecessary entry when there exists a trace that go back to this entry point 
2. gather number of function translated for each benchmark; 
1. if there are multiple inputs, calculates the average
2. use google doc to gather these data
3. trace guided layout has no influence for performance, why?
1. maybe wrong benchmarks, I've tried gcc, which one should I try?

QUESTION:

1. GCC, trace-method performs bad than method; Evidence shows that T-M used more than 4 times IBTC than method.  WHY???  The problem may be in the transition between 
1. Running test inputs and output trace profile; see what we got...
2. shit happen: how to stop optimization thread when execution thread logout...
3. Any IDEA?
4. It is because there is too many trace/method to build such that we still spend too much time on block fragment.

TODO:

1' prove that FP has been fix

2' prove trace-guilded layout works

3' prove partial inline works

3' prove chained partial inline works

Question:

gcc is strange: 1. does it trace-threshold-sensitive? 2. does it function-threshold-sensitive?

TFTP + NFS boot openrd-ultimate

TFTP + NFS boot openrd-ultimate

1, install Debian in USB as described in http://www.cyrius.com/debian/kirkwood/openrd/install.html

2, after success installation, login to Debian system

3, edit /etc/initramfs-tools/initramfs.conf, find "BOOT=local", change it to "BOOT=nfs";

4, issue "update-initramfs -u" to get new /boot/uImage and /boot/uInitrd.

5, shutdown the system, copy the base system to /opt/openrd/nfs, which is exported via NFS.
5.1, Edit /opt/openrd/nfs/etc/fstab to comment out all local mount since there is no local file system after NFS boot. Otherwise, debian would try to mount root file system again after NFS boot

6, copy /opt/openrd/nfs/boot/{uImage,uInitrd} to /opt/openrd/tftp/{uImage,uInitrd}

7, start Openrd-Ultimate, enter u-boot, set environments
set mainlineLinux yes
set arcNumber 2884
set ipaddr=192.168.1.2
set serverip=192.168.1.1
set console 'console=ttyS0,115200n8'
set nfs 'mtdparts=orion_nand:0x400000@0x100000(uImage),0x1fb00000@0x500000(rootfs) rw root=/dev/nfs rw nfsroot=192.168.1.1:/opt/openrd/nfs'
set ip 'ip=192.168.1.2:192.168.1.1:192.168.1.1:255.255.255.0:DB88FXX81:eth0:none'
set bootargs $(console) $(nfs) $(ip)
set bootcmd 'tftpboot 0x01100000 uInitrd; tftpboot 0x00800000 uImage; bootm 0x00800000 0x01100000'
saveenv
reset

8, After restart, should be able use tftp to load uImage and uInitrd, and mount NFS directory /opt/openrd/nfs as root filesystem

libquantum problem

libquantum has performance lost

why?

Check ibtc and shack hit ratio
they are the same!

don't know
check all version!

segmentation fault:
1' where?
0x00007fffe0000158
0x00007fffe8000168
0x00007fffe8000078
0x00007fffe0000158

This address seems strange
jit_event_listener

try debug version

turn off AddShackPush in trace, wait and see...
still seg fault, re-implement
should always try both single thread version, multi-thread version

Reason:
timing plus inappropriate block_map
when translating a block, the block info is inserted into block_map
at beginning of translation process, which violates the assumption of block map.
We assume all infos in block map are valid, which means they have host code address where the translated code at. However, at the beginning of translation, we didn't know the exact address of the translated block. As a result, when the trace builder doing AddShackPush, it found the incomplete block in the block map, and uses its address.
Therefore, we modified the code as the following:
1. block info is added immoderately after the location of the translated block is known, which is in NotifyFunctionEmitted of jit_event_listener.h.
2. the query is delayed until we are going to patch the shack point.

However, in this experiment, I found shadow stack is quietly in-effect to performance,
plus it consumes more memory, and makes code complex. It seems more reasonable not to use shack when trace is available.

Debug cactusADM. Died in signal 9.
Cannot move on
Keep gen trace_

1. add print_pc
2. assert re-genereated trace
3. possible reason:
somehow it traps within a block...., why?
self loop?

Fight!
Timing!
why....

a -> b -> c -> c -> c -> c -> c -> c ...
a->b->c->b->c->b->c->b->c->b

Possibility:
1' trace gen die. or no response.
which ca

Trace: Path/Cycle with duplicate nodes
CFG: Graph with unique nodes

Need convert Trace to Graph

run native run

dispatch+translate+optimize
execution, test and set

TII

TII->isMoveInstr(*DefMI, SrcReg, DstReg, SrcSubIdx, DstSubIdx)