From mboxrd@z Thu Jan 1 00:00:00 1970 From: Greg McGary To: fche@redhat.com (Frank Ch. Eigler) Cc: cgen@sourceware.cygnus.com Subject: Re: PATCH: string-expansion macros Date: Mon, 16 Apr 2001 12:58:00 -0000 Message-id: References: <200103022358.QAA31874.cygnus.local.cgen@kayak.mcgary.org> X-SW-Source: 2001-q2/msg00013.html fche@redhat.com (Frank Ch. Eigler) writes: > : I'd like to know why the old code tried to match macros before hard > : insns? The reason I need to try hard insns before macros is that for > : my MIPS-like port, string macros catch cases that can't be handled by > : one insn, and implement a "virtual insn" that do things in 2 or 3 hard > : insns. [...] > > Yes, this makes sense in most cases, but methinks there are other > opposite cases also. Can you think of an example? > It would be nice to control ordering preference > by some attribute. OK. How about this: macro insns with attribute "POST" are forced to match after real insns. > The biggest part that bothers me is that conditional messing-about > with the md_assemble function. FYI, it didn't bother the gas maintainers. That part of the patch was approved a couple weeks ago. > Rather than call it recursively like this, Where do you see recursion? > I'd much rather see use of the gas sb (string-buffer) structure, > and treatment as expanded gas macro bodies. That's what I'm doing. Can you suggest a better way? Greg