Javacat posted on Feb 5 2006 at 07:18 PM said:
In an interview with him in 1999 he said he was Chinese and currently studying in America. That was 7 years ago (scary!), so he will probably be back in China now.
Maybe it would be worth getting in touch with some of the people that helped him translate corn to different languages?
I found something. Perhaps this will help to understand the Way Corn works a bit better.
QUOTE:
The author of Corn has written an excellent explanation of why Corn is so fast. He has also sent me some trouble shooting tips.
Various reasons for Corn's speed:
1. Static Recompilation Static rec is the main technique that Corn experiment wants to test. In theory, static rec should be faster than dynamic rec since the branch/call overhead is much lower. And, with static rec, we can afford to do sophisticated optimizations like a real compiler does. Although the actual implementations can greatly affect the real performance.
On the other hand, static rec becomes the major deficiency of Corn. It makes corn need individual configuration to run each rom. So, in terms of compatibility, it is not a good approach. Probably this is the main reason why other emulator authors did not try it before(in my knowledge). Between compatibility and speed, most authors will choose the former. If Corn was not started as an experiment, I would have chosen dynamic rec also.
Right now, the optimization done in Corn is still simple. So, probably not much speed (10%-25%?) really come from this part at this time. Later, I will try to apply more advanced optimization techniques to study the power of static rec, which is the main goal of this experiment.
2. 32bit vs 64bit As first mentioned by UltraHLE, practically N64 games are 32bits programs. However, there do exist 64bit instructions in some (though very rare) OS functions. Since UltraHLE emulates OS functions, this is not a problem. Corn uses low-level emulation (for CPU part), so it must single them out and patch them. This is another place where compatibility is greatly lowered. I guess 20%-40% speed come from this part.
3. Incomplete emulation The RDP emulation in Corn is still very incomplete. Many effects, features have not been implemented. Some very time-consuming things are ignored. There is almost no support for combine modes, just some sort of hack. Honestly, Corn still needs lots of work to reach the stage that Nemu and TRWin achieved. I expect at least 30% speed drop of RDP emulation in the furture. Also, Audio task is short-circuited. As Corn implements more and more features, speed come from this part will disappear. I guess currently 30%-60% speed come from this part.
4. Implementation issues I has a relatively low-end pc. So, I have to push the speed in every corner. Once I suspect that a C compiler cannot optimize some part very well, and that part is important, I use inline assembly codes. For example,
C cannot handle bit operations very efficiently, so in Corn, most of this job is done by inline assembly codes. There are many such things. Each of them is not significant, but when they add up, I guess the contribution is about 20%-50%.
5. Some bad things A good program should have codes to handle errors, extreme cases etc. They are not existent in current version of Corn. Corn always assumes a good run-time environment. It may be practically acceptable, but definitely not a good programming style. I guess 5%-10% speed come from this part.
The above percentages are just my feelings. They may be wrong.
QUOTE END
Check the underlined things. Not much optimisation! (?? Is this a english word ??)
P.S. Some things in there could be outdated, because this was released before Corn 0.01
P.P.S. But don't stop searching, please
I still have some questions for him.
