On Wed, May 16, 2012 at 1:23 PM, R. Diez <[email protected]> wrote: > I was hoping to get support for at least the basic exceptions like "invalid > instruction" or "range error", so that most of the simple test cases from > other test suites (like division by zero) can run without modifications on > the CGEN simulator.
This is reasonable and I intend to do it, it's just not done yet :) > In fact, I had a quick go and I think the CGEN simulator fails some simple > division tests (I have to check again). I wonder what other things are > broken. There are probably several other things that are broken, too. This is just the first go at it, though, give it time :) > Do you mean the simulator is only needed to run the GCC and/or GDB test > suites? The whole point is then just to avoid having to build or1ksim > beforehand? If that's the case, I don't think maintaining another (very > crippled) simulator is worth the effort. As you know, I have written an > automated build framework which can build and test everything together with > little effort. The right thing to do would be to let the framework run all > those checks against both or1ksim and an Icarus Verilog simulation of > ORPSoC's or1200 core. Basically, this CGEN simulator will be able to do most things that or1ksim can do, except for virtual memory, and emulating off-core devices. (It may someday be able to do the latter, actually). The advantage of it, even with those limitations, is that it's generated from the same machine description as the assembler, integrates with gdb easily, and the GCC testsuite is designed to use it for executing testcases. Since it shares the same framework as the assembler, the maintenance overhead is low, and any changes to the assembler can be easily added to the simulator with very minimal effort. And part of all this work is to get our toolchain integrated with the upstream repositories. Having a CGEN base simulator in the toolchain will help a lot towards that effort, since the upstream devs can then use it for testing after they make changes, without having to know about the way we do things on our end. This is the officially "blessed" way for GNU toolchains to make simulators. -Pete _______________________________________________ OpenRISC mailing list [email protected] http://lists.openrisc.net/listinfo/openrisc
