1/1 
|
[or1ksim] Fix generate.c
by Unknown on Jan 24, 2005 |
Not available! | ||
|
Hi,
This is my attempt at fixing generate.c to produce far less warnings than it
currently does. I have also fixed the simulator when compiled with the
--enable-simple configure switch. You may want to propogate the changes I made
to or32.c and or32.h to the other places where the files are referenced, just to
keep them insync.
Odly enough I have found minimal speed diferences when running with
--enable-simple and when running without.
I sugest that the cpu/or32/execgen.c be removed from cvs as it is dynamicaly
generated from insnset.c.
You may also want to update the configure script (and all the other files that
depend on configure.in) in cvs as it is older than configure.in.
ChangeLog:
* Fix generate.c to produce a execgen.c with less warnings.
* Fix the --enable-simple configure option.
nog.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: patch2.gz
Type: application/x-gunzip
Size: 9848 bytes
Desc: not available
Url : http://www.opencores.org/forums/openrisc/attachments/20050124/bdfa48f2/patch2-0001.bin
|
|||
|
[or1ksim] Fix generate.c
by Unknown on Jan 25, 2005 |
Not available! | ||
|
* György 'nog' Jeney (nog@sdf.lonestar.org) wrote:
Hi,
This is my attempt at fixing generate.c to produce far less warnings than it currently does. I have also fixed the simulator when compiled with the --enable-simple configure switch. You may want to propogate the changes I made to or32.c and or32.h to the other places where the files are referenced, just to keep them insync. Odly enough I have found minimal speed diferences when running with --enable-simple and when running without. I sugest that the cpu/or32/execgen.c be removed from cvs as it is dynamicaly generated from insnset.c. That would actully break the build of or1ksim. If i'm not mistaken if you do a build in seperate directory than the one with source files the execgen.c from source files will be used... So we should fix the makefiles too....
You may also want to update the configure script (and all the other files that
depend on configure.in) in cvs as it is older than configure.in. Ok, the problem here is with automake tools on the opencores server. They are quite old, and ussualy the ATS builds then fail. regards, p. |
|||
|
[or1ksim] Fix generate.c
by Unknown on Jan 25, 2005 |
Not available! | ||
|
On 0, Matjaz Breskvar phoenix@opencores.org> wrote:
> I sugest that the cpu/or32/execgen.c be removed from cvs as it is dynamicaly
> generated from insnset.c. That would actully break the build of or1ksim. If i'm not mistaken if you do a build in seperate directory than the one with source files the execgen.c from source files will be used... So we should fix the makefiles too.... I'll have a look at it.
> You may also want to update the configure script (and all the other files that
> depend on configure.in) in cvs as it is older than configure.in. Ok, the problem here is with automake tools on the opencores server. They are quite old, and ussualy the ATS builds then fail. So the server should generate these dynamically? Wouldn't it suffice if the maintainer of or1ksim regenerated these files when needed? They really don't change that often. nog. |
|||
|
[or1ksim] Fix generate.c
by Unknown on Jan 25, 2005 |
Not available! | ||
|
Just one comment. The or32.h and or32.c are links even in cvs, so changing
Yes, that that patch to or32.h does break binutils and gdb. Here is one that
doesn't. Patch #4 applies with a bit of fuzz, but it is still correct.
ChangeLog:
* Fix generate.c to produce a execgen.c with less warnings.
* Fix the --enable-simple configure option.
nog.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: patch2.gz
Type: application/x-gunzip
Size: 9905 bytes
Desc: not available
Url : http://www.opencores.org/forums/openrisc/attachments/20050125/2ba0a725/patch2-0001.bin
them in or1ksim means changing them also in other places like binutils, gdb... Although the changes may work nicely in or1ksim they might break a bunch of other stuff. Did you maybe try the changes in binutils... ? |
|||
1/1