headers
Hans-Peter Nilsson | 1 Dec 2004 03:32
Picon
Favicon

sim: Handle and pass new required option -OPC for CGEN "desc".

Most CGEN-based simulators use the <target>-desc.h file from
opcodes (and by most, I mean two out of the total three), see
sim/m32r/Makefile.in and sim/frv/Makefile.in.  When the CGEN
option "-OPC" was introduced for generating that file, the CGEN
caller in opcodes was updated, but the one in sim wasn't.  So
i960 broke.  To repeat, build sim --target=i960-elf
--enable-cgen-maint or go to build/sim/i960 and make
"stamp-desc" (may need to "rm stamp-desc" or "touch
cgen/cpu/i960.cpu").  You'll see:

make cgen-desc CGEN=`if [ -f ../../guile/libguile/guile ]; then echo ../../guile/libguile/guile;
else echo guile ; fi` CGENFLAGS="-v" \
  cpu=i960 mach=all \
  archfile=/n/asic/slask/hp/simtest/src/sim/i960/../../cgen/cpu/i960.cpu
make[1]: Entering directory `/n/asic_slask/hp/simtest/srcobji960/sim/i960'
/bin/sh /n/asic/slask/hp/simtest/src/sim/i960/../common/cgen.sh desc
/n/asic/slask/hp/simtest/src/sim/i960 \
guile /n/asic/slask/hp/simtest/src/sim/i960/../../cgen "-v" \
	i960 "" i960 "" all "" \
	/n/asic/slask/hp/simtest/src/sim/i960/../../cgen/cpu/i960.cpu ignored
Skipping slib/sort, already loaded.
Skipping slib/random, already loaded.
No backtrace available.
cgen -s /n/asic/slask/hp/simtest/src/sim/i960/../../cgen/cgen-opc.scm -s
/n/asic/slask/hp/simtest/src/sim/i960/../../cgen -v -f  -m all -a
/n/asic/slask/hp/simtest/src/sim/i960/../../cgen/cpu/i960.cpu -i all -H tmp-desc.h1 -C
tmp-desc.c1 -O tmp-opc.h1 
Loading cpu description /n/asic/slask/hp/simtest/src/sim/i960/../../cgen/cpu/i960.cpu
Including file simplify.inc ...
Analyzing instruction set ...
(Continue reading)

Permalink | Reply | 0 comments |
headers
Frank Ch. Eigler | 1 Dec 2004 14:53
Picon
Favicon
Gravatar

Re: sim: Handle and pass new required option -OPC for CGEN "desc".

Hi, HP -

On Wed, Dec 01, 2004 at 03:32:59AM +0100, Hans-Peter Nilsson wrote:
> [...]
> I didn't
> commit the regenerated sim/i960 files, because they obviously
> haven't been regenerated since CGEN was last modified and
> they're too different from the version in CVS for me to decide
> whether the changes are benevolent, and there's no testsuite for
> it trigged by "make check-sim". :-(  [...]

Testsuites for "check-sim" are quite rare.  The way one normally
obtains confidence in regenerated simulators is by running the
gcc/gdb tests against the changed sim.

Thanks for your care & feeding of cgen.  (I'll get back to
you on the other cris stuff later today.)

- FChE
Permalink | Reply | 0 comments |
headers
Hans-Peter Nilsson | 1 Dec 2004 16:02
Picon
Favicon

Re: sim: Handle and pass new required option -OPC for CGEN "desc".

> Date: Wed, 1 Dec 2004 08:53:40 -0500
> From: "Frank Ch. Eigler" <fche <at> redhat.com>

> Testsuites for "check-sim" are quite rare.  The way one normally
> obtains confidence in regenerated simulators is by running the
> gcc/gdb tests against the changed sim.

A *very* weak confidence, and a roundabout way of doing it at
that!  I just want to raise a concern: I hope it isn't policy.

(I like test-suites, and ones exercising existing-code coverage,
functional coverage and fixed bugs is a minimum.  I could
rewrite the whole thing and not worry -- except of course to
check that the new code paths are covered!)  Besides, i960 is
obsoleted, removed from gcc, so no hope in current CVS for that.

> Thanks for your care & feeding of cgen.  (I'll get back to
> you on the other cris stuff later today.)

So they all say. :-)  I'd be most thankful to get that SID issue
resolved.  What are y'all using for CGEN debugging?  I tried
psd-1.2.1 but it doesn't seem guile-compatible.

brgds, H-P
Permalink | Reply | 0 comments |
headers
Frank Ch. Eigler | 3 Dec 2004 01:46
Picon
Favicon
Gravatar

Re: Committed: src/cpu/cris.cpu, intended for src/sim/ src/sid/component/cgen-cpu/ but some problems

Hi, HP -

On Mon, Nov 29, 2004 at 01:02:26PM +0100, Hans-Peter Nilsson wrote:
> [...]
> With SID, a complete system boots and runs Linux on CRISv32.  

Wow.

> Considering that both SID and sim work as dejagnu baseboards (at
> least by brief inspection of dejagnu), why have both?  Well, sim
> is the snap-in-simulator of choice for GCC testing (my main
> purpose for it) and asking people to build SID instead is a
> obstacle.  

Plus sid is not as well known, and some people have expressed
reservations about Red Hat retaining its copyright over the
core of the software.

> Also, at the time I wrote it (perhaps still the case), I couldn't
> find a way to model cycle-correctness for the SID simulator.

We have a really wild sid port (MeP) that does model the pipeline
in much the same way that the sim/common/cgen* stuff does (and goes
way beyond in some other ways), and I believe this does not rely on
any sid/cgen infrastructure not already public.

> [...]
> Processing extractor fn bodies ...
> Processing extractor for "#f" ...
> Processing extractor for "(#f 16  (f-operand2 #) (f-operand1 #)  (-nosan- Rs SI) (-nosan- f-operand2
(Continue reading)

Permalink | Reply | 0 comments |
headers
Hans-Peter Nilsson | 3 Dec 2004 03:08
Picon
Favicon

Re: Committed: src/cpu/cris.cpu, intended for src/sim/ src/sid/component/cgen-cpu/ but some problems

> Date: Thu, 2 Dec 2004 19:46:46 -0500
> From: "Frank Ch. Eigler" <fche <at> redhat.com>

> Plus sid is not as well known, and some people have expressed
> reservations about Red Hat retaining its copyright over the
> core of the software.

BTW, we'll have to resolve the copyright issue for the CRISv32
sid port and assorted components to be merged.  For all I know
(and I should know) Axis is happy with the current license terms
(GPL but allowing binary distributions IIRC), but we do not want
to assign copyright for them to Red Hat.  (To FSF is ok).  Is
there a defined path for contributing to SID without copyright
assignment to Red Hat?  Can this be solved?  (I thought such a
path was in progress of being defined a year ago or so, or sid
copyright assigned to the FSF or suchlike.)

> We have a really wild sid port (MeP) that does model the pipeline
> in much the same way that the sim/common/cgen* stuff does (and goes
> way beyond in some other ways), and I believe this does not rely on
> any sid/cgen infrastructure not already public.

Cool.  Want that!  Will put on my TODO list to investigate.
Hints welcome.

> > [...]
> > Processing extractor fn bodies ...
> > Processing extractor for "#f" ...
> > Processing extractor for "(#f 16  (f-operand2 #) (f-operand1 #)  (-nosan-=
>  Rs SI) (-nosan- f-operand2 UINT) (-nosan- h-raw-gr-SI-index-of--DFLT-Rd SI=
(Continue reading)

Permalink | Reply | 0 comments |
headers
Frank Ch. Eigler | 3 Dec 2004 05:42
Picon
Favicon
Gravatar

Re: Committed: src/cpu/cris.cpu, intended for src/sim/ src/sid/component/cgen-cpu/ but some problems

Hi -

> > Plus sid is not as well known, and some people have expressed
> > reservations about Red Hat retaining its copyright over the
> > core of the software.
> 
> BTW, we'll have to resolve the copyright issue for the CRISv32
> sid port and assorted components to be merged.  [...]
> Is there a defined path for contributing to SID without copyright
> assignment to Red Hat?  Can this be solved?  

We have been taking contributions to sid and cgen without formal
copyright assignment: your copyright would just get added to
the list.  CGEN needs to be modified to be taught this, to avoid
the rubber-stamping of "Copyright (C) Red Hat" in sid-bound
generated files.

> (I thought such a
> path was in progress of being defined a year ago or so, or sid
> copyright assigned to the FSF or suchlike.) [...]

That was for eCos, a process which sadly appears stalled.

- FChE
Permalink | Reply | 0 comments |
headers
fche | 4 Dec 2004 15:13
Favicon

new cgen snapshot available

A new automated cgen CVS snapshot is available.
ftp://sources.redhat.com/pub/cgen/snapshots/snapshot-20041204.tar.bz2
Permalink | Reply | 0 comments |
headers
Jim Blandy | 16 Dec 2004 17:50
Picon
Favicon

RFA: use /dev/tty for debugging interaction


2004-12-13  Jim Blandy  <jimb <at> redhat.com>

	* read.scm (debug-repl): Temporarily redirect input and output to
	/dev/tty while we debug, so we don't interfere with whatever CGEN
	is reading or writing.
	* utils.scm (setter-getter-fluid-let, with-input-and-output-to):
	New functions.

Index: cgen/read.scm
===================================================================
RCS file: /cvs/cvsfiles/devo/cgen/read.scm,v
retrieving revision 1.32
diff -c -p -r1.32 read.scm
*** cgen/read.scm	20 Oct 2003 01:25:22 -0000	1.32
--- cgen/read.scm	16 Dec 2004 16:44:31 -0000
*************** Define a preprocessor-style macro.
*** 963,968 ****
--- 963,979 ----

  (define (debug-var name) (assq-ref debug-env name))

+ ; A handle on /dev/tty, so we can be sure we're talking with the user.
+ ; We open this the first time we actually need it.
+ (define debug-tty #f)
+ 
+ ; Return the port we should use for interacting with the user,
+ ; opening it if necessary.
+ (define (debug-tty-port)
+   (if (not debug-tty)
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jim Blandy | 16 Dec 2004 18:06
Picon
Favicon

RFA: make parse-name handle lists containing symbols properly


Not sure why the 1.6.4 porting work didn't catch this.

2004-12-13  Jim Blandy  <jimb <at> redhat.com>

	* utils-cgen.scm (parse-name): Don't assume that string-map can be
	applied to symbols.  Process everything as strings, and then
	convert to a symbol at the end.

Index: cgen/utils-cgen.scm
===================================================================
RCS file: /cvs/cvsfiles/devo/cgen/utils-cgen.scm,v
retrieving revision 1.61
diff -c -p -r1.61 utils-cgen.scm
*** cgen/utils-cgen.scm	20 Oct 2003 01:25:22 -0000	1.61
--- cgen/utils-cgen.scm	16 Dec 2004 17:05:38 -0000
***************
*** 175,185 ****
  ; FIXME: Isn't the plan to move ERRTXT to the 1st arg?

  (define (parse-name name errtxt)
!   (cond ((list? name)
! 	 (string->symbol (string-map (lambda (elm) (parse-name elm errtxt)) name)))
! 	((symbol? name) name)
! 	((string? name) (string->symbol name))
! 	(else (parse-error errtxt "improper name" name)))
  )

  ; Parse an object comment.
--- 175,187 ----
(Continue reading)

Permalink | Reply | 0 comments |
headers
fche | 18 Dec 2004 15:13
Favicon

new cgen snapshot available

A new automated cgen CVS snapshot is available.
ftp://sources.redhat.com/pub/cgen/snapshots/snapshot-20041218.tar.bz2
Permalink | Reply | 0 comments |

Gmane