On Wed, 3 Oct 2007, Thiemo Seufer wrote: > Then you have the worst of both approaches: The nicely readable > disassembly will change under you feet, and you still need relocation > annotations etc. for CPU-specific fixups. The end-result is likely > more complicated and opaque than what we have now. Well, to be honest what we have now is very good. One trouble at the beginning, just after we switched from the old approach, was limited ability to get at what really is generated and therefore tough time to determine what was going on if something was wrong. With these debug dumps in place it is gone now too. There is one limitation though -- unlike with ready-writted assembly to debug this code you typically need to have a specific system that shows a problem. If you do not have one chances are you can miss a condition somewhere and therefore the problem. Once you have the right piece of hardware, debugging is easy -- it took me half of a day if not less to sort out all the issues with the R3000 TLB handlers that we had once I got my hands on a suitable system. And as with everything, there is still room for improvement though. For example I have noticed for the 64-bit TLB refill handler the path for vmalloc()ed pages may fit entirely in half of the space available. Which means whatever is emitted after "eret" may be shifted to the TLB refill space at 0x80000000 saving the branch from the XTLB space at its end. That is probably doable with reasonably little effort given that we have support for "relocations". Maciej
