* [patch][commit] New (if (...) (...) (...)) Test Allowed at Top Level of the Input
@ 2006-05-10 17:57 Dave Brolley
2006-05-10 18:11 ` Doug Evans
0 siblings, 1 reply; 6+ messages in thread
From: Dave Brolley @ 2006-05-10 17:57 UTC (permalink / raw)
To: cgen
[-- 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))))))
)
^ permalink raw reply [flat|nested] 6+ messages in thread* [patch][commit] New (if (...) (...) (...)) Test Allowed at Top Level of the Input
2006-05-10 17:57 [patch][commit] New (if (...) (...) (...)) Test Allowed at Top Level of the Input Dave Brolley
@ 2006-05-10 18:11 ` Doug Evans
2006-05-11 11:52 ` Thien-Thi Nguyen
0 siblings, 1 reply; 6+ messages in thread
From: Doug Evans @ 2006-05-10 18:11 UTC (permalink / raw)
To: Dave Brolley; +Cc: cgen
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))))))
> )
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [patch][commit] New (if (...) (...) (...)) Test Allowed at Top Level of the Input
2006-05-10 18:11 ` Doug Evans
@ 2006-05-11 11:52 ` Thien-Thi Nguyen
2006-05-11 14:12 ` Dave Brolley
0 siblings, 1 reply; 6+ messages in thread
From: Thien-Thi Nguyen @ 2006-05-11 11:52 UTC (permalink / raw)
To: cgen
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
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: [patch][commit] New (if (...) (...) (...)) Test Allowed at Top Level of the Input
2006-05-11 11:52 ` Thien-Thi Nguyen
@ 2006-05-11 14:12 ` Dave Brolley
2006-05-11 16:45 ` Jim Blandy
0 siblings, 1 reply; 6+ messages in thread
From: Dave Brolley @ 2006-05-11 14:12 UTC (permalink / raw)
To: ttn; +Cc: cgen
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [patch][commit] New (if (...) (...) (...)) Test Allowed at Top Level of the Input
2006-05-11 14:12 ` Dave Brolley
@ 2006-05-11 16:45 ` Jim Blandy
2006-05-11 20:52 ` Doug Evans
0 siblings, 1 reply; 6+ messages in thread
From: Jim Blandy @ 2006-05-11 16:45 UTC (permalink / raw)
To: Dave Brolley; +Cc: ttn, cgen
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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [patch][commit] New (if (...) (...) (...)) Test Allowed at Top Level of the Input
2006-05-11 16:45 ` Jim Blandy
@ 2006-05-11 20:52 ` Doug Evans
0 siblings, 0 replies; 6+ messages in thread
From: Doug Evans @ 2006-05-11 20:52 UTC (permalink / raw)
To: Jim Blandy; +Cc: Dave Brolley, ttn, cgen
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.]
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2006-05-11 20:52 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2006-05-10 17:57 [patch][commit] New (if (...) (...) (...)) Test Allowed at Top Level of the Input Dave Brolley
2006-05-10 18:11 ` Doug Evans
2006-05-11 11:52 ` Thien-Thi Nguyen
2006-05-11 14:12 ` Dave Brolley
2006-05-11 16:45 ` Jim Blandy
2006-05-11 20:52 ` Doug Evans
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).