From: Doug Evans <dje@transmeta.com>
To: Greg McGary <greg@mcgary.org>
Cc: cgen@sourceware.cygnus.com, binutils@sourceware.cygnus.com
Subject: Re: how to implement general macro-insn expansion?
Date: Wed, 27 Dec 2000 11:28:00 -0000 [thread overview]
Message-ID: <14922.17101.201404.651828@casey.transmeta.com> (raw)
In-Reply-To: <mselyu1vw3.fsf@mcgary.org>
Greg McGary writes:
> I had originally stated that I wanted to first implement the most
> general scheme form of expansion (sequence () ...). Since then, I
> have changed my mind, since none of the multi-insn macro expansions
> need runtime evaluation, and string substitution suits me just fine.
> Now, I'm faced with gas's inadequacy to handle general multi-insn
> macro expansion at the machine-dependent layer.
Some notes:
1) I was kind of thinking the macro-insn expander would call
appropriate insn emitters rather than doing string substitution.
That doesn't preclude going the latter route though.
One goal of cgen is to have a large part of the assembler in
a library, gas then becoming just one user of the library.
Whether macro-insns should be part of this library I dunno.
At the very least, don't tie the specification of macro-insns
to any gas implementation artifacts.
> read_a_source_file() is the outer machine-independent loop that
> handles all assembler directives (a.k.a. pseudo-ops) and only invokes
> the machine-dependent md_assemble() when it has a line that looks like
> an instruction. md_assemble() operates on a single line only.
> read_a_source_file() can handle gasp macro expansion, but that doesn't
> fit with the macro-insn model. The strength of macro-insns is that a
> single opcode can be overloaded to handle multiple insns (both real
> insns and 1:n macros) differentiated by operand formats and actual
> operand values (e.g., MIPS). We can't know until we're inside
> md_assemble and subsidiaries if we have a macro insn, but it's outside
> md_assemble that we want to push the old input source's context take
> input from the new input source which is the macro's expansion string.
2) Is this something that has to be handled at a layer above md_assemble?
For example, I'm not sure I want to support the result of the expansion
containing pseudo-ops.
One can implement this macro-processing in a reasonable way without
returning from md_assemble (assuming the result of the
macro-expansion only contains things that md_assemble should
otherwise handle).
> I see no way around the need to change the md_assemble() interface.
> Somehow md_assemble() needs to return a `sb' (string block)
> representing the expansion of a macro-insn so that read_a_source_file()
> can push it as a nested input source and continue assembling. A
> sneaky way to do this that doesn't require changing any of the
> zillions of instances of md_assemble is to pass a zeroed sb as a
> second argument, then detect macro-insn by whether or not the sb's
> fields come back filled-in. However, I don't like sneakiness and gas
> is sourceware, so I'm content to hack all instances of md_assmeble to
> take the second argument and return a boolean to indicate what we did.
> md_assmble() should return nonzero if it assembled an insn, and should
> return 0 if a macro expansion was deposited into `sb'.
>
> Sound reasonable?
>
> Greg
next prev parent reply other threads:[~2000-12-27 11:28 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2000-12-18 12:02 multi-insn expansions for macro insns? Greg McGary
2000-12-18 13:09 ` Doug Evans
2000-12-18 13:17 ` Greg McGary
2000-12-18 13:41 ` Doug Evans
2000-12-19 22:54 ` how to implement general macro-insn expansion? Greg McGary
2000-12-20 0:48 ` Greg McGary
2000-12-20 7:39 ` Doug Evans
2000-12-26 17:43 ` Greg McGary
2000-12-27 11:28 ` Doug Evans [this message]
2000-12-27 12:09 ` Greg McGary
2000-12-27 14:21 ` Doug Evans
2001-01-09 15:23 ` Greg McGary
2000-12-27 10:39 Nick Clifton
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=14922.17101.201404.651828@casey.transmeta.com \
--to=dje@transmeta.com \
--cc=binutils@sourceware.cygnus.com \
--cc=cgen@sourceware.cygnus.com \
--cc=greg@mcgary.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).