This is the mail archive of the
cgen@sourceware.org
mailing list for the CGEN project.
Re: [patch][commit] New (if (...) (...) (...)) Test Allowed at Top Level of the Input
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.