fche | 4 Jun 16:13 2005

new cgen snapshot available

A new automated cgen CVS snapshot is available.
ftp://sources.redhat.com/pub/cgen/snapshots/snapshot-20050604.tar.bz2

Dave Brolley | 8 Jun 22:18 2005

[RFC] New cpu --- Morpho ms1

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)

fche | 11 Jun 16:13 2005

new cgen snapshot available

A new automated cgen CVS snapshot is available.
ftp://sources.redhat.com/pub/cgen/snapshots/snapshot-20050611.tar.bz2

Frank Ch. Eigler | 13 Jun 16:54 2005
Picon

Re: [RFC] New cpu --- Morpho ms1

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
Jim Blandy | 14 Jun 00:27 2005
Picon

PATCH: let .upcase and .downcase pmacros handle symbols


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)

Nick Clifton | 14 Jun 12:28 2005
Picon

Re: [RFC] New cpu --- Morpho ms1

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

Dave Brolley | 15 Jun 17:40 2005
Picon

Re: [RFC] New cpu --- Morpho ms1

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

Dave Brolley | 15 Jun 23:36 2005
Picon

Re: [RFC] New cpu --- Morpho ms1

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)

Doug Evans | 15 Jun 23:46 2005

Re: [RFC] New cpu --- Morpho ms1

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)

Dave Brolley | 16 Jun 16:21 2005
Picon

Re: [RFC] New cpu --- Morpho ms1

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)


Gmane