public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
* gas: flag_mri vs. flag_m68k_mri vs. macro_mri
@ 2005-01-25 11:48 Jan Beulich
  2005-01-25 19:18 ` Ian Lance Taylor
  0 siblings, 1 reply; 2+ messages in thread
From: Jan Beulich @ 2005-01-25 11:48 UTC (permalink / raw)
  To: binutils

Can anyone tell me what the reason for duplicating the information held
by these three variables is? macro_mri exactly follows flag_mri, and
flag_m68k_mri, for the only case where it is not #define-d to 0, also
does. Thus it would seem to me that macro_mri could be replaced by
flag_mri; for flag_m68k_mri it would need to be checked whether there
indeed are differences between MRI mode under TC_M68K vs. all other
architectures. If so, (at least) some of the macro handling (e.g.
buffer_and_nest) seems to incorrectly refer to macro_mri where I would
think flag_m68k_mri is meant.

Thanks, Jan

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: gas: flag_mri vs. flag_m68k_mri vs. macro_mri
  2005-01-25 11:48 gas: flag_mri vs. flag_m68k_mri vs. macro_mri Jan Beulich
@ 2005-01-25 19:18 ` Ian Lance Taylor
  0 siblings, 0 replies; 2+ messages in thread
From: Ian Lance Taylor @ 2005-01-25 19:18 UTC (permalink / raw)
  To: Jan Beulich; +Cc: binutils

"Jan Beulich" <JBeulich@novell.com> writes:

> Can anyone tell me what the reason for duplicating the information held
> by these three variables is? macro_mri exactly follows flag_mri, and
> flag_m68k_mri, for the only case where it is not #define-d to 0, also
> does. Thus it would seem to me that macro_mri could be replaced by
> flag_mri; for flag_m68k_mri it would need to be checked whether there
> indeed are differences between MRI mode under TC_M68K vs. all other
> architectures. If so, (at least) some of the macro handling (e.g.
> buffer_and_nest) seems to incorrectly refer to macro_mri where I would
> think flag_m68k_mri is meant.

The difference between flag_mri and macro_mri is due to the now
vanished gasp program.  The macro expansion code was shared by gas and
gasp, so it used a private variable, macro_mri, controlled through the
macro_mri_mode() interface.  This duplication could be removed now
that gasp no longer exists.


flag_m68k_mri exists simply to avoid sprinkling #ifdef TC_M68K all
over the place.  There is code which should only be run for m68k MRI
mode.  We used to just check flag_mri, then I found out that the m68k
MRI assembler was unusual, and that other MRI assemblers were much
more similar to gas.  That change was made here:

Tue Feb  6 15:16:17 1996  Ian Lance Taylor  <ian@cygnus.com>

	* as.h (flag_m68k_mri): Declare.
	* as.c (parse_args): If TC_M68K, set flag_m68k_mri for -M.
	* Many files: For MRI syntax that is specific to the m68k MRI
	assembler, check flag_m68k_mri rather than flag_mri or
	MRI_MODE_NEEDS_PSEUDO_DOT.


I agree that the usage in buffer_and_nest() looks fishy.
Unfortunately my experience is that you can not change this code
without test cases, which means access to the MRI assemblers.  I no
longer have that; I don't know whether anybody here does.

Ian

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2005-01-25 19:18 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2005-01-25 11:48 gas: flag_mri vs. flag_m68k_mri vs. macro_mri Jan Beulich
2005-01-25 19:18 ` Ian Lance Taylor

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).