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".