[patch][commit] New (if (...) (...) (...)) Test Allowed at Top Level of the Input

[patch][commit] New (if (...) (...) (...)) Test Allowed at Top Level of the Input

[Dave Brolley]

[-- Attachment #1: Type: text/plain, Size: 399 bytes --]

Hi,

I've committed the attach patch. I allows the psecification of

(if (application-is? <appname>)
    (true expr)
    (false expr))

at the top level of the CGEN input. This test corresponds to (eq? 
application <appname>) which is found in many places in the CGEN source. 
For example

(if  (application-is? SID-SIMULATOR)
     (include "sid-macros.cpu")
     (include "sim-macros.cpu"))

Dave


[-- Attachment #2: cgen-if.ChangeLog --]
[-- Type: text/plain, Size: 179 bytes --]

2006-05-10  Dave Brolley  <brolley@redhat.com>

	* read.scm (cmd-if): Provide the correct argument to reader-error. Add
	support for (if (application-is? <appname>) (...) (...)).

[-- Attachment #3: cgen-if.patch.txt --]
[-- Type: text/plain, Size: 1330 bytes --]

Index: cgen/read.scm
===================================================================
RCS file: /cvs/src/src/cgen/read.scm,v
retrieving revision 1.13
diff -c -p -r1.13 read.scm
*** cgen/read.scm	10 May 2006 16:24:53 -0000	1.13
--- cgen/read.scm	10 May 2006 17:45:17 -0000
*************** Define a preprocessor-style macro.
*** 796,803 ****
  		    (cons 'if (cons test (cons then else)))
  		    ""))
    ; ??? rtx-eval test
!   (if (not (memq (car test) '(keep-isa? keep-mach?)))
!       (reader-error "only (if (keep-mach?|keep-isa? ...) ...) is currently supported"))
    (case (car test)
      ((keep-isa?)
       (if (keep-isa? (cadr test))
--- 796,803 ----
  		    (cons 'if (cons test (cons then else)))
  		    ""))
    ; ??? rtx-eval test
!   (if (not (memq (car test) '(keep-isa? keep-mach? application-is?)))
!       (reader-error "only (if (keep-mach?|keep-isa?|application-is? ...) ...) are currently supported" test ""))
    (case (car test)
      ((keep-isa?)
       (if (keep-isa? (cadr test))
*************** Define a preprocessor-style macro.
*** 810,815 ****
--- 810,821 ----
  	 (eval1 then)
  	 (if (null? else)
  	     #f
+ 	     (eval1 (car else)))))
+     ((application-is?)
+      (if (eq? APPLICATION (cadr test))
+ 	 (eval1 then)
+ 	 (if (null? else)
+ 	     #f
  	     (eval1 (car else))))))
  )
  

[patch][commit] New (if (...) (...) (...)) Test Allowed at Top Level of the Input

[Doug Evans]

Blech.


Dave Brolley writes:
 > Hi,
 > 
 > I've committed the attach patch. I allows the psecification of
 > 
 > (if (application-is? <appname>)
 >     (true expr)
 >     (false expr))
 > 
 > at the top level of the CGEN input. This test corresponds to (eq? 
 > application <appname>) which is found in many places in the CGEN source. 
 > For example
 > 
 > (if  (application-is? SID-SIMULATOR)
 >      (include "sid-macros.cpu")
 >      (include "sim-macros.cpu"))
 > 
 > Dave
 > 
 > 2006-05-10  Dave Brolley  <brolley@redhat.com>
 > 
 > 	* read.scm (cmd-if): Provide the correct argument to reader-error. Add
 > 	support for (if (application-is? <appname>) (...) (...)).
 > Index: cgen/read.scm
 > ===================================================================
 > RCS file: /cvs/src/src/cgen/read.scm,v
 > retrieving revision 1.13
 > diff -c -p -r1.13 read.scm
 > *** cgen/read.scm	10 May 2006 16:24:53 -0000	1.13
 > --- cgen/read.scm	10 May 2006 17:45:17 -0000
 > *************** Define a preprocessor-style macro.
 > *** 796,803 ****
 >   		    (cons 'if (cons test (cons then else)))
 >   		    ""))
 >     ; ??? rtx-eval test
 > !   (if (not (memq (car test) '(keep-isa? keep-mach?)))
 > !       (reader-error "only (if (keep-mach?|keep-isa? ...) ...) is currently supported"))
 >     (case (car test)
 >       ((keep-isa?)
 >        (if (keep-isa? (cadr test))
 > --- 796,803 ----
 >   		    (cons 'if (cons test (cons then else)))
 >   		    ""))
 >     ; ??? rtx-eval test
 > !   (if (not (memq (car test) '(keep-isa? keep-mach? application-is?)))
 > !       (reader-error "only (if (keep-mach?|keep-isa?|application-is? ...) ...) are currently supported" test ""))
 >     (case (car test)
 >       ((keep-isa?)
 >        (if (keep-isa? (cadr test))
 > *************** Define a preprocessor-style macro.
 > *** 810,815 ****
 > --- 810,821 ----
 >   	 (eval1 then)
 >   	 (if (null? else)
 >   	     #f
 > + 	     (eval1 (car else)))))
 > +     ((application-is?)
 > +      (if (eq? APPLICATION (cadr test))
 > + 	 (eval1 then)
 > + 	 (if (null? else)
 > + 	     #f
 >   	     (eval1 (car else))))))
 >   )
 >   

Re: [patch][commit] New (if (...) (...) (...)) Test Allowed at Top Level of the Input

[Thien-Thi Nguyen]

   From: Doug Evans <dje@transmeta.com>
   Date: Wed, 10 May 2006 11:10:55 -0700 (PDT)

   Blech.

   Dave Brolley writes:

    > I've committed the attach patch. I allows the psecification of
    > 
    > (if (application-is? <appname>)
    >     (true expr)
    >     (false expr))
    > 
    > at the top level of the CGEN input. This test corresponds to (eq? 
    > application <appname>) which is found in many places in the CGEN source. 
    > For example
    > 
    > (if  (application-is? SID-SIMULATOR)
    >      (include "sid-macros.cpu")
    >      (include "sim-macros.cpu"))

why not allow computed `include' instead?  (perhaps that is already
supported?)  something like:

(include EXPR)

then EXPR can be all manner of `if', `cond' or whatever.  e.g.:

(include (if (application-is? SID-SIMULATOR)
             "sid-macros.cpu"
             "sim-macros.cpu"))

(include (cond ((application-is? SID-SIMULATOR)
                "sid-macros.cpu")
               (else "sim-macros.cpu")))

(include (case (application->symbol APPLICATION-OBJECT)
           ((SIMULATOR) "sid-macros.cpu")
           (else "sid-macros.cpu")))

going from `if' to `cond' gets you extensibility.  going from `cond' to
`case' gets you regularity and some namespace separation, providing you
are in the mood for a certain style of symbolic manipulation...

thi

Re: [patch][commit] New (if (...) (...) (...)) Test Allowed at Top Level of the Input

[Dave Brolley]

Thien-Thi Nguyen wrote:

>why not allow computed `include' instead?  (perhaps that is already
>supported?)  something like:
>
>(include EXPR)
>
>then EXPR can be all manner of `if', `cond' or whatever.  e.g.:
>
>(include (if (application-is? SID-SIMULATOR)
>             "sid-macros.cpu"
>             "sim-macros.cpu"))
>
>(include (cond ((application-is? SID-SIMULATOR)
>                "sid-macros.cpu")
>               (else "sim-macros.cpu")))
>
>(include (case (application->symbol APPLICATION-OBJECT)
>           ((SIMULATOR) "sid-macros.cpu")
>           (else "sid-macros.cpu")))
>
>  
>
The point isn't really the (include "..."). That's just what I happened 
to use the 'if' capability for. The true and false expressions could 
theoretically be any valid top level CGEN construct. Implementing 
conditional capability for them all seems like a lot more work for no 
gain and may not even make sense in some cases. Also 'cond' or 'case' 
could easily be added as top level tests if necessary.

Dave

Re: [patch][commit] New (if (...) (...) (...)) Test Allowed at Top Level of the Input

[Jim Blandy]

On 5/11/06, Dave Brolley <brolley@redhat.com> wrote:
> Thien-Thi Nguyen wrote:
>
> >why not allow computed `include' instead?  (perhaps that is already
> >supported?)  something like:
> >
> >(include EXPR)
> >
> >then EXPR can be all manner of `if', `cond' or whatever.  e.g.:
> >
> >(include (if (application-is? SID-SIMULATOR)
> >             "sid-macros.cpu"
> >             "sim-macros.cpu"))
> >
> >(include (cond ((application-is? SID-SIMULATOR)
> >                "sid-macros.cpu")
> >               (else "sim-macros.cpu")))
> >
> >(include (case (application->symbol APPLICATION-OBJECT)
> >           ((SIMULATOR) "sid-macros.cpu")
> >           (else "sid-macros.cpu")))
> >
> >
> >
> The point isn't really the (include "..."). That's just what I happened
> to use the 'if' capability for. The true and false expressions could
> theoretically be any valid top level CGEN construct. Implementing
> conditional capability for them all seems like a lot more work for no
> gain and may not even make sense in some cases. Also 'cond' or 'case'
> could easily be added as top level tests if necessary.

The larger question is, why aren't CGEN machine description files just
arbitrary Scheme code that happens to call some functions to register
machine description pieces?  Then you'd have the full Scheme language
at your disposal, not just pmacros.

None of this would complicate the interesting parts of CGEN --- the
code for producing encoders, decoders, and simulators.  They would
operate on the same data structures they do now.  You'd just have a
lot more flexibility in how those structures are produced.

Re: [patch][commit] New (if (...) (...) (...)) Test Allowed at Top Level of the Input

[Doug Evans]

Jim Blandy writes:
 > The larger question is, why aren't CGEN machine description files just
 > arbitrary Scheme code that happens to call some functions to register
 > machine description pieces?  Then you'd have the full Scheme language
 > at your disposal, not just pmacros.

I can explain why things are the way they are today.
The powers that be can of course change things however they please.

I didn't (and still don't) want (arbitrary) Scheme in .cpu files.
Maybe CGEN will be written in multiple language some day
(once one has a .cpu database reader, the choice of language
for file generators and such is less important).
I'd hate to have to rewrite all the .cpu files, or maintain multiple
versions, or etc.; or implement all of Scheme just to read the .cpu file in.
I look at .cpu files as a description of the cpu, and I don't
want the reading of that description to be excessively complicated.

Another consequence in allowing arbitrary Scheme is that .cpu files
would become harder to read and maintain.

[
One can quibble of course over whether and how much of Scheme is
already in .cpu files :-).  I think there's even some places where
I provided too much of an escape hatch in order to get something done
(e.g. .eval).  But I think one would be hardpressed to argue
that using a different language would be no harder after N years of
allowing arbitrary Scheme to appear in .cpu files.  As things stand today,
reading the database is rather simple compared with being required
to understand all of Scheme.  I can even imagine having just one database
reader in C(/C++) and then having all generators use it, regardless
of language.

Of course, if one wants to stick with just Scheme then there is
less reason for not allowing it in .cpu files.
]

Having said that, I wouldn't switch from Scheme myself.
But the point is others can for a particular file generator
once the database reader is written.
I WOULD switch from Guile to something better.
One dream I have is to have a Scheme implementation that does dynamic
compilation using a framework built from CGEN.

 > None of this would complicate the interesting parts of CGEN --- the
 > code for producing encoders, decoders, and simulators.  They would
 > operate on the same data structures they do now.  You'd just have a
 > lot more flexibility in how those structures are produced.

IMO (and this is just my opinion) I'd rather restrict the description
of the cpu, and make it easier to use that description.

[Hmmm,
One could have a generator that read in a .cpu with arbitrary Scheme
and spit out a copy ready for consumption by a different language,
but it feels like the wrong way to go.]