#119 Add %(EL)IF(N)(REG|MEM|IMM)(<bits>) directives
I have implemented a macro that requires, as the first
argument, a 16 or 32-bit register, and has slightly
different behaviour depending on the size of the
supplied register, using a local copy with an
implementation of %TOK2STR and lots of string comparisons.
This would have been much easer with
%ifreg32 %1
; r32 code
%elifreg16 %1
; r16 code
%else
%error "Requires a 16 or 32-bit register."
%endif
REG, above, means general purpose register, but maybe
%(EL)IF(N)REG should prohibit size indicators, and
catch all of GPR(8|16|32), SEGREG, MMX, XMMS,
FP(64|80), &c. Or maybe that's just featuritis.
Another possibility would be to make <bits> an optional
second argument, only permitted on certain forms.
I'm not sure how useful the %(EL)IF(N)(MEM|IMM)<bits>
forms would be, but I can definitely see uses for
%(EL)IF(N)(MEM|IMM).
Logged In: YES
user_id=804543
My short answer is: a more powerful preprocessor
eliminates the need for these directive. I have
filed numerous SF RFEs on that front. Also, take
a look at
http://cvs.tortall.net/pipermail/yasm-devel/attachments/20060917/6f01af82/attachment-0001.txt
to get an idea of how the resulting preprocessor
looks as a whole.
Also, here a few additional thoughts...
> %(EL)IF(N)REG
As you pointed out yourself, this quickly leads
to featuritis. For example, which 8-bit GPRs are
you looking for -- all of them, or just the ones
that can only/not be used in 64-bit mode. Like-
wise, which SREGs -- all of them, or just those
that are available on a pre-386?
> %(EL)IF(N)MEM
Keep in mind that effective addresses don't have
to be as simple as "[...]" -- there can be size
qualifiers before the "[", and, in fact, the "[]"
can be replaced by a leading "&" (a la AT&T). In
general, not a simple thing to parse for in the
preprocessor. You would literally want to invoke
the parser.c code... which leads to...
> %(EL)IF(N)IMM
Keep in mind that immediate operands may contain
expressions (as can effective addresses, btw). As
a result, this is a slippery slope: you would need
to look for critical expressions to avoid chances
of getting a phase error (see e.g. SF #797816). In
addition you would have to suppress errors inside
the evaluator, which is not safe (because they may
have been caused e.g. by memory management problems
during (de)allocation).
Anyway. As you can see I did consider putting such
directives into the NASM64 preprocessor but ended
up going for different "basic building blocks" in-
stead, which IMO is more powerful.