On Fri, May 11, 2012 at 12:33 PM, Peter Gavin <[email protected]> wrote:
> 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.

Nice one mate.

I'm not sure if I drew your attention to it a while back but I got gdb
sim to about the same stage (could run helloworld.)

https://github.com/juliusbaxter/binutils-or1k/tree/gdb-sim-addon/sim

(it was on a different branch.)

I never got useful tracing out of it, though. I just got the result,
essentially.

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

I'm not sure we need one to help verify the newlib-based toolc hain.

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

Again, I'm not sure I'd bother with that.

What we want is something to run bare metal stuff. That'd be enough.

Cheers

Julius
_______________________________________________
OpenRISC mailing list
[email protected]
http://lists.openrisc.net/listinfo/openrisc

Reply via email to