4 Jun 2005 16:13
8 Jun 2005 22:18
[RFC] New cpu --- Morpho ms1
Dave Brolley <dave.brolley <at> rogers.com>
2005-06-08 20:18:58 GMT
2005-06-08 20:18:58 GMT
Hello, On behalf of Red Hat I would like approval to commit the attached ms1.cpu and ms1.opc files for CGEN to the src/cpu directory. I will also be submitting the opcodes and SID ports to their respective lists. Dave
; Morpho Technologies mRISC CPU description. -*- Scheme -*- ; Copyright (C) 2001 Red Hat, Inc. ; This file is part of CGEN. ; See file COPYING.CGEN for details. (include "simplify.inc") ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ;; Define The Architecture, Attributes, ISA, CPU, Machine, And Model. ;; ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ; define-arch must appear first (define-arch (name ms1) ; name of cpu family (comment "Morpho Technologies mRISC family") (default-alignment aligned) (insn-lsb0? #t) (machs ms1 ms1-003) (isas ms1) )(Continue reading)
11 Jun 2005 16:13
13 Jun 2005 16:54
Re: [RFC] New cpu --- Morpho ms1
Frank Ch. Eigler <fche <at> redhat.com>
2005-06-13 14:54:52 GMT
2005-06-13 14:54:52 GMT
Hi - On Wed, Jun 08, 2005 at 04:18:58PM -0400, Dave Brolley wrote: > [...] > On behalf of Red Hat I would like approval to commit the attached > ms1.cpu and ms1.opc files for CGEN to the src/cpu directory. From what I gather, src/cpu contains FSF-reassigned files. If the intent is to donate ms1.* in this way, go ahead. If not, then they are welcome under cgen/cpu. > I will also be submitting the opcodes and SID ports to their > respective lists. With respect to cgen/sid-bound sources, commit at will. - FChE
14 Jun 2005 00:27
PATCH: let .upcase and .downcase pmacros handle symbols
Jim Blandy <jimb <at> redhat.com>
2005-06-13 22:27:27 GMT
2005-06-13 22:27:27 GMT
This fixes another problem caused by tighter typechecking in modern versions of Guile. I've committed it. 2005-06-13 Jim Blandy <jimb <at> redhat.com> * pmacros.scm (-pmacro-upcase, -pmacro-downcase): Handle symbols as well as strings. Index: cgen/pmacros.scm =================================================================== RCS file: /cvs/src/src/cgen/pmacros.scm,v retrieving revision 1.4 diff -c -p -r1.4 pmacros.scm *** cgen/pmacros.scm 14 Feb 2005 17:48:25 -0000 1.4 --- cgen/pmacros.scm 13 Jun 2005 22:26:06 -0000 *************** *** 424,436 **** ; .upcase - convert a string to uppercase (define (-pmacro-upcase str) ! (string-upcase str) ) ; .downcase - convert a string to lowercase (define (-pmacro-downcase str) ! (string-downcase str) )(Continue reading)
14 Jun 2005 12:28
Re: [RFC] New cpu --- Morpho ms1
Nick Clifton <nickc <at> redhat.com>
2005-06-14 10:28:19 GMT
2005-06-14 10:28:19 GMT
Hi Dave, These files are approved for contribution into the <binutils>/cgen/cpu directory. Of course we would prefer it if the copyright on these files was assigned to the FSF and then they could be contributed to the <binutils>/cpu directory. Perhaps you could ask RedHat management if this could be done ? Cheers Nick
15 Jun 2005 17:40
Re: [RFC] New cpu --- Morpho ms1
Dave Brolley <brolley <at> redhat.com>
2005-06-15 15:40:34 GMT
2005-06-15 15:40:34 GMT
Nick Clifton wrote: > Hi Dave, > > These files are approved for contribution into the > <binutils>/cgen/cpu directory. > > Of course we would prefer it if the copyright on these files was > assigned to the FSF and then they could be contributed to the > <binutils>/cpu directory. Perhaps you could ask RedHat management if > this could be done ? > Yes, this was the intent. I have changed the copyrights of both files using the copyrights from the frv files as a template and have committed these files to the <binutils>/cpu directory. Dave
15 Jun 2005 23:36
Re: [RFC] New cpu --- Morpho ms1
Dave Brolley <brolley <at> redhat.com>
2005-06-15 21:36:47 GMT
2005-06-15 21:36:47 GMT
Frank Ch. Eigler wrote: >>I will also be submitting the opcodes and SID ports to their >>respective lists. >> >> > >With respect to cgen/sid-bound sources, commit at will. > > > I've committed, on behalf of Red Hat and the original author, Graydon Hoare, the attached patch which implements, for SID only, an implementation of delayed read/writes which is useful for implementing cpus with exposed pipelines, delay slots and parallel execution. I think the user level description which has been added cgen/doc/rtl.texi describes the new functionality pretty well. There is no effect on existing SID ports or opcodes. This new functionaility has been used in the implementation of the Morpho ms1 (patch on the way). This patch also adds the automatic generation of streaming methods for cgen hardware to each cpu. Regards, Dave Dave(Continue reading)
15 Jun 2005 23:46
Re: [RFC] New cpu --- Morpho ms1
Doug Evans <dje <at> transmeta.com>
2005-06-15 21:46:38 GMT
2005-06-15 21:46:38 GMT
Eewwwww! Imagine if bison or autoconf had encoded in them knowledge of particular applications that used them. [The analogy doesn't port 1-1, but the eewww-ness is equivalent.] Dave Brolley writes: > Index: cgen/rtl-c.scm > =================================================================== > RCS file: /cvs/src/src/cgen/rtl-c.scm,v > retrieving revision 1.5 > diff -c -p -r1.5 rtl-c.scm > *** cgen/rtl-c.scm 16 Jul 2003 05:35:47 -0000 1.5 > --- cgen/rtl-c.scm 15 Jun 2005 20:58:26 -0000 > *************** > *** 1305,1311 **** > "bad arg to `operand'" object-or-name))) > ) > > ! (define-fn xop (estate options mode object) object) > > (define-fn local (estate options mode object-or-name) > (cond ((rtx-temp? object-or-name) > --- 1305,1327 ---- > "bad arg to `operand'" object-or-name))) > ) > > ! (define-fn xop (estate options mode object) > ! (let ((delayed (assoc '#:delay (estate-modifiers estate)))) > ! (if (and delayed(Continue reading)
16 Jun 2005 16:21
Re: [RFC] New cpu --- Morpho ms1
Dave Brolley <brolley <at> redhat.com>
2005-06-16 14:21:34 GMT
2005-06-16 14:21:34 GMT
Hi Doug, Certainly some of the scheme code used by CGEN knows exactly what 'application' is using it: sid*.scm, sim*.scm, cgen-sid.scm, cgen-sim.scm I guess that with these one would argue that these source files *are* the 'application'. What we have here are functions which are called by several 'applications' which to analyse the same data but which require different output. I imagine that there must be some way to separate the different logic into the application-specific source files. My knowledge of scheme isn't the greatest so please do make suggestions! Thanks, Dave Doug Evans wrote: >Eewwwww! > >Imagine if bison or autoconf had encoded in them knowledge of particular >applications that used them. >[The analogy doesn't port 1-1, but the eewww-ness is equivalent.] > > >(Continue reading)
RSS Feed