This is the mail archive of the cgen@sourceware.org mailing list for the CGEN project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]