Re: Proposed addition to gpasm

Craig Franklin writes:
 > I took a very brief look at your changes.  This looks like a feature we 
 > can incorporate into gpasm.  Before we do that:
 > 
 > - I would like to hear any objections people might have.  This looks 
 > good to me.  Anyone have a better idea?
 > - Bill, do you consider this complete for absolute mode?

	Yes.  I am working on additions to apply to absolute freg
expressions in relocatable mode, but it's good for absolute mode.

 > - Any known regressions?

	If there are standard regression tests for gpasm, I don't
know about them and haven't run them.  I know of no reason for the
behavior to be different under --strict-mpasm from the behavior of
an unmodified assembler.  They produce identical results using my
test file, which hammars at the most likely area.

	Code assembled without --strict-mpasm and which uses, say, a
macro named assume, or a define named __SUPPORTS_ASSUME, for its own
purposes, may break.  This seems acceptible to me because the names
are unlikely, but others may differ.  I'm pretty sure that assume as a
directive name is in a separate namespace from user address symbols,
meaning that you can still have a variable or label named assume.  You
probably know that better than I do.  I haven't tested it..  The only
possible alternative is to use a command line switch to enable the
extension, rather than using --strict-mpasm to disable it.

	It is possible that (not under --strict-mpasm) some cases of
multiple errors, warnings, and/or messages on the same source line
will come out in a different order.  Probably the only folks who could
care are those using a regression test that expects a fixed pattern of
error messages.  (Actually, I'd like to let this happen even under
--strict-mpasm for my next set of changes, if we go forward.  If
someone actually cares, I'd like to hear about it.)

							Bill