Menu
▾
▴
#32 Another way to multiline comment
Common multiline comment conceptions means to
comment source text and there was no way to use them
automatically in macros. I want to propose a new way -
lowlevel directive, that affects on result code generation:
[emit off] - stops code emitting
[emit on] - starts code emitting
This will be wery useful in libraries to remove code part
automatically.
Logged In: NO
You'd have to be very precise about the definition
of such a directive. Would it merely suppress any
code or data bytes from being emitted? Or would it
suppress each and every byte from being emitted,
e.g. certain records in an object file? Also, what
about items other than code or data? Would labels
still be defined? If so, then would that be safe?
Lots of questions. Lots of details to be resolved.
Personally I think that the existing conditional
assembly stuff in the preprocessor is sufficient.
Logged In: YES
user_id=806493
No labels, no instructions, no data - like all code between
[emit off] and [emit on] is cutted.
It will work after preprocessor and preprocessor macros may
control code emitting.
Here is example and my nasm improvements plan is to make
this syntax possible:
<foo.inc>
SOURCE "foo.asm"
HEAD foo, NEAR
<some descriptions/>
ENDH foo
HEAD bar, NEAR
<some descriptions/>
ENDH bar
</foo.inc>
<main.asm>
%include "lib.mac"
ProgramStart "Main"
<some code/>
%include "foo.inc"
<some code/>
call foo
<some code/>
ProgramEnd
</main.asm>
<foo.asm>
PROC foo, NEAR
<some code/>
ENDP foo
PROC bar, NEAR ;Would not be included
<some code/>
ENDP bar
</foo.asm>
HEAD/HEAD will describe procedure and define single line macro
no_<name> (or the same) and specify dependencies with
procedures.
Overloaded call will check for existing of no_<name> and
undefine it (and also check the dependencies). I am now
vorking on preprocessor improvements to allow parsing complex
expressions such as 'far[label]'.
PROC will check for no_<name> too and will forbid emitting
with [emit off] until ENDP's [emit on].
SOURCE will describe where the source code is laying for
post-include.
ProgramStart will initialize something.
ProgramEnd will post-include sources and finish the program.
There is my libraty conception and I now working on its
implementation.
PS:
You can say that such behaviour of PROC ENDP can be
realized by enclosing them in %ifndef no_<name>/%endif, but I
maintain it would be better to have [emit].
Logged In: NO
Let me try to phrase it in my own terms, to see whether
we are talking about the same thing. :-)
You want to introduce a flag in nasm.c, which is toggled
by an assembler directive, and which controls whether the
main loop, after calling preproc->getline(), attempts to
process assembler directives and instructions, or whether
it just continues to the next preproc-getline() call? Or
in other words: you want to be able to enable/disable the
assembler portion of NASM. (If so, then this should be
rather easy to implement. With one gotcha: even when the
assembler portion is disabled, it would still have to re-
cognize that one assembler directive which re-enables it.)
In case we are on the same page here, might I suggest a
better name than [EMIT]? Perhaps something like [ASM], so
that we can also add a [PP] directive, which would control
the preprocessor (NASM or null, or others in the future).
Logged In: YES
user_id=806493
Yes, exactly, you are right :-)
[EMIT] was the first name occurred to me. And I like [ASM]
more.
[PP] directive is good idea. But maybe to give it another
name?
I think, this is one of nasm progress directions - environment
control from the source code (environment variables access
with %!<name>, generally comand-line options switching and
so on).
PS:
One of [PP] switches may be 'TASM'.
Logged In: YES
user_id=804543
How about [PREPROC pp_name] then?
Logged In: YES
user_id=806493
Yes, it would be better.
About [ASM]. What do you think about stack-like usage of this
directive (in addition to immediate flag change by ON/OFF),
like this:
[ASM DOWN]
<some code/>
[ASM DOWN]
<some code/>
[ASM UP]
<some code/>
[ASM UP]
UP and DOWN is for example.
Logged In: YES
user_id=804543
I'm not sure I understand.
Do you mean keeping an unsigned integer counter
instead of a boolean flag? (Sort of.)
Logged In: YES
user_id=806493
Yes, in addition.
Logged In: YES
user_id=804543
I have managed to implement the boolean version
of the [ASM] assembler directive. In essence I
introduced a new boolean flag to assemble_file()
which I'm setting to TRUE at the beginning of
each pass. Next, I'm passing said flag as a new
argument to getkw(), so that it can first check
for the new [ASM] directive, then return -1 if
the flag is TRUE, and finally check for all the
other assembler directives -- this ensures that
[ASM] can be used to re-enable the assembler
whenever it has been disabled. Furthermore I've
added code to assemble_file()'s switch(i), to
handle [ASM] similar to [LIST]: on "-" it sets
the new flag to FALSE, on "+" it sets it to TRUE,
and otherwise it emits a non-fatal error. Last
but not least I modified the "else" clause that
is commented with "/* it isn't a directive */",
to say "else if ( new_flag == TRUE )", so that
the new flag takes effect.
I did not yet implement a version of [ASM] that
uses an unsigned integer counter, simply because
I'm still not 100% sure as to how it's supposed
to work and/or be useful. Perhaps you can give
me a better example.
However, I did add a corresponding ASM macro in
standard.mac, which invokes [ASM], and updates
the definition of __ASM__: it defines said macro
on "+", but undefines it on "-" -- this allows
the user to query/save the current state, modify
it, and finally restore the original state. (In
my forked version of NASM I'm keeping such double
underscore macros for most assembler directives,
so that state can be queried/saved/restored.)
Last but not least, I looked into implementing
the proposed [PREPROC] assembler directive.
I've come to the conclusion that it can _not_ be
done. The (two existing) preprocessors keep dif-
ferent internal state, which would have to be
synced whenever the preprocessor gets switched.
Furthermore, the NASM preprocessor supports re-
cursive include files, but the null preprocessor
does not. So switching between those two might
require switching between files, which of course
isn't going to work in any sane manner.
It is no doubt possible to make [PREPROC] work;
however, at this time I don't think that it is
worth the effort. (In fact, personally I believe
that my [PREPROC] idea should be dropped, instead
of being post-poned. :-)
Logged In: YES
user_id=806493
Great! New powerful mechanism is working!
What about counter: I am not sure it is a best way too.
But I am sure, I don't like single-line macro clone of [ASM] too.
If user changes something (for example, [SECTION xxx]
instead SECTION xxx)
immediately, preprocessor doesn't know about this.
What are you thinking about saving/restoring states of flags in
internal stack, like this:
%macro foo 0
[ASM SAVE]
[ASM -]
%endmacro
%macro bar 0
[ASM RESTORE]
%endmacro
And this may be done with section/absolute too (for
struc/endstruc improvement).
What do you think?
What about PREPROC: we should not implement something we
did not consider well. There is no need in this directive now, so
put it aside.
Logged In: YES
user_id=804543
> But I am sure, I don't like single-line macro clone
> of [ASM] too.
My version of ASM is a multi-line macro. It not only
invokes [ASM], but also defines or undefines __ASM__,
depending on whther "+" or "-" was specified.
> What are you thinking about saving/restoring states
> of flags in internal stack, like [...]
Check out SourceForge #656015 -- it's about the very
same fundamental issue.
For numeric state I've considered using labels... but
that won't work for strings, e.g. __FILE__. :-(
Logged In: YES
user_id=806493
What are you thinking about complete assembler state
storing/loading with something like this:
[STATE PUSH] to store state in internal stack;
[STATE POP] to load state from internal stack.
This directive will save state of
SEGMENT/SECTION/ABSOLUTE, BITS, CPU, LIST, WARNING
and ASM.
With such a directive it will be able to insert something like
stuct into arbitrary place of source code simply.
Example:
<foo.asm>
[SECTION .data]
[BITS 16]
...
[STATE PUSH] ; Saving previous state
[SECTION .text]
[BITS 32]
<some 32-bit code/>
[STATE POP] ; Restoring previous state
...
</foo.asm>
Because we have no feedback from assembler to
preprocessor, this is the best way of interaction between
them.
Do you agree with me?
Logged In: YES
user_id=804543
See my latest comment on/in #656015.
Lets keep that topic over there.
We'll finalize this one -- [ASM] -- once #656015 has been
resolved.