#20 design question: global or local?
Currently the effects of the [WARNING], the [CPU], and
the [LIST] directives are global. I'd like us to investigate
whether they should be context-local instead, i.e. save
their state on %PUSH, and restore it on %POP.
Making them context-local would allow users to switch
to their own settings -- e.g. within a multi-line macro --
and then return to the previous settings. This would be
useful in scenarios where someone -- me :-) -- writes a
library, that requires particular settings, but has no way
of querying them before modifying them, i.e no way of
modifying them and then restoring them.
Of course the same scenario can be used "against" my
proposal: there might be code which, inside a context,
modifies those settings, assuming that the new settings
will remain in effect accross the %POP.
This issue (as well as the one of backward compatibility
with previous versions of NASM) could be addressed by
making this whole thing optional, e.g. via a command-
line option, selecting between global (default) and con-
text-local.
Personally I think that context-local makes more sense
for this stuff. What do you think?
Logged In: NO
Another possibility would be to use __SECT__-like
variables. For example, the LIST macro could define
and undefine a __LIST__ variable, while the [LIST]
directive wouldn't touch that variable. Then the
user could switch via [LIST], and use __LIST__ to
restore the previous state.
However, this approach would pretty much require
that warnings or CPU flags be kept numerically. In
other words: assign a bit for each warning, and for
each CPU flag, and keep them in a __WARNING__ and
a __CPU__ variable, respectively. Though it would
be a bit messy to write such WARNING or CPU macros,
it is no doubt possible.
The downside is that [WARNING] and [CPU] would have
to learn how to set all warnings or CPU flags, based
on a numeric input value. Which wouldn't pose a big
problem... if it weren't for the fact that the [CPU]
directive already supports such flags as "386". How
would the directive know, whether "386" refers to
the Intel 80386 flag, or 386 = 182h = 1_1000_0010b
which would stand for three particular CPU flags?
One solution would be to use hexadecimal numbers for
the __WARNING__ and __CPU__ variables, and teach
NASM how to differ between those numbers, and the
old-fashioned arguments. Possible, but messy.
Last but not least, this whole approach would still
suffer from at least one more shortcoming: one can
not use it recursively. For example, assume LIST
was used to enable list file emission, and __LIST__
reflects that. Then macro ONE disables it via [LIST].
Next, macro TWO is invoked by macro ONE. It too is
using [LIST]. But when it tries to restore the old
state via __LIST__, it gets the pre-ONE state, not
the pre-TWO state.
Granted, this is a simple, benign example. But it
illustrates the core problem.
Mmh.
Interesting problem.
Maybe warnings and CPU flags should be handled the
way you suggested, i.e. be context-local.
PS: I've checked MASM. It has PUSHCONTEXT as well
as POPCONTEXT, which can push and pop the state of
a few things, including the listing flags, and the
CPU flags. Sounds like a reasonable precedent.
Logged In: NO
The [FPU] directive, proposed
in SourceForge bug #746314, is
also going to fall into this
category.
Logged In: YES
user_id=804543
The [ASM] directive, proposed
in SourceForge request #763038,
is also going to fall into this
category.
Logged In: YES
user_id=804543
For numeric state we could maintain __XYZ__ labels.
Unlike single-line macros, they would be available
even when the preprocessor is disabled via the -a
option. However, they'd only work for numeric state.
Logged In: YES
user_id=804543
In #763038, Nickolay suggested [STATE PUSH|POP].
Sort of like MASM's PUSHCONTEXT and POPCONTEXT.
By now I have come to believe that -- if it has
to be implemented -- a stack-like implementation
would be the way to go, and that it would have
to reside in the assembler, not the preprocessor.
However...
Would it make sense to have the ability to save
and restore a selected piece of state, and leave
the selection to the user? Or would it be better
to always save and restore the entire state?
Also, what about the ability to query the current
state? Again, __XYZ__ labels would work, but only
for numeric state. (I think that __SECT__ is the
only non-numeric state right now, no?)
Personally I think that the ability to query se-
lected state is very important. And once there is
a means to do so, the user can save and restore
it... without the need for a(ny) new directive(s).
Read: currently I'm leaning towards __XYZ__ labels.
But I want/need to think about this some more...
Logged In: YES
user_id=804543
Implementing %SCOPE...%ENDSCOPE, %IMPORTS, and %EXPORTS
as described in
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n161
4.pdf
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n162
5.pdf
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n172
6.pdf
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n174
0.pdf
might be another (even more powerful) possibility.
I'll look into it...
Logged In: YES
user_id=804543
Btw, blame SF for wrapping those URLs. :(
Logged In: YES
user_id=804543
Btw, blame SF for wrapping those URLs. :(
Logged In: YES
user_id=804543
As well as double-submitting. :((
Logged In: YES
user_id=804543
I have a working prototype. It supports nestable %SCOPE
and %ENDSCOPE, but instead of %IMPORT and %EXPORT (which
would impact the order of smac and mmac definitions) it
provides %=id, %==id, %===id, etc. to refer to an outer
scope. The scope applies to preprocessor variables and
single-line macros (smac) as well as multi-line macros
(mmac), but not to context-local preprocessor variables
or single-line macros (ctx->smac).
I plan to test this prototype implementation further.
If it "works out", then I will file a separate SF RFE.
Logged In: YES
user_id=804543
see SF RFE #1512493 for preprocessor scope support