public inbox for cgen@sourceware.org
 help / color / mirror / Atom feed
From: Doug Evans <dje@sebabeach.org>
To: cgen@sourceware.org
Subject: ALIAS instructions are messed up?
Date: Thu, 18 Jun 2009 17:27:00 -0000	[thread overview]
Message-ID: <4A3A78E5.5030503@sebabeach.org> (raw)

Blech.  Handling of ALIAS instructions is messed up.

 From insn.scm:-insn-parse:

        (let ((ifield-assertion (if (not (null? ifield-assertion))
                                    ifield-assertion
                                    #f))
              (semantics (if (not (null? semantics))
                             semantics
                             #f))
              (format (-parse-insn-format (string-append errtxt " format")
                                          fmt))
              (comment (parse-comment comment errtxt))
              ; If there are no semantics, mark this as an alias.
              ; ??? Not sure this makes sense for multi-insns.
              (atlist-obj (if semantics
                              atlist-obj
                              (atlist-cons (bool-attr-make 'ALIAS #t)
                                           atlist-obj)))
              (syntax (parse-syntax syntax errtxt))
              (timing (parse-insn-timing errtxt timing))
              )

If this were a `let*', then things would be a bit clearer, but not 
completely.
[the checking for alias insns won't work if it's expecting the previous 
assignment of semantics to change () to #f]

This comes up because generating the html doc for xc16x.cpu crashes 
because its "nop" instruction has () for semantics.

I can't remember if there's any usefulness to ALIAS insns that isn't 
provided by macro-insns.
Can anyone?

I don't have too strong a preference on what to do here (though I 
reserve the right to change my mind :-)).
Since, e.g., simulators rightly ignore ALIAS insns it seems like we want 
to flag insns in .cpu files with missing/empty semantics as an error and 
not silently convert them to aliases.
Nop insns would be required to specify (nop) for their semantics.
It'd be interesting to see if making this change causes any changes to 
the generated code.

Whether to disallow alias insns entirely is a separate question.  Dunno.
[We could still keep it for macro-insns.
And I realize there are a few ports that currently use it, or at least 
specify it.]

             reply	other threads:[~2009-06-18 17:27 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-06-18 17:27 Doug Evans [this message]
2009-10-03 20:33 Joern Rennecke
2009-10-05 18:22 ` Doug Evans
2009-10-05 21:42   ` Joern Rennecke

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4A3A78E5.5030503@sebabeach.org \
    --to=dje@sebabeach.org \
    --cc=cgen@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).