On Fri, May 11, 2012 at 10:38 AM, Jeremy Bennett <[email protected]> wrote: > Before we do this, we need to break the circular dependency between > Or1ksim and the tool chain (using it as the GDB simulator). Your work on > CGEN should solve that. > > GDB has the same problem, because it maintains its own copy of the > binutils libraries, and they have now diverged. This will be fixed when > we have a unified source tree build (which I believe you are doing).
Yes, and I've made decent progress on it. The GNU CGEN simulator will run small test programs now. The problem is that CGEN doesn't give you an easy way to make full-system simulators. It's primary purpose is writing syscall emulated simulators. For instance, there's no easy way that I can see to simulate the TLBs without hacking the framework. (I've been trying to avoid changing the framework as much as possible, to avoid breaking the other architectures.) Handling virtual memory for loads and stores should be pretty easy, but there's no way to intercept and translate the PC before an instruction is fetched. The simulator also caches the results of decoding instructions to speed things up. It caches one basic-block at a time, and since a basic block can cross between two pages, that can cause some difficulty. -Pete _______________________________________________ OpenRISC mailing list [email protected] http://lists.openrisc.net/listinfo/openrisc
