Menu
▾
▴
#24 %macro & strings related...
1.if one declares %macro mac_name 2
and %macro
mac_name 1
%undef mac_nam - is unpredictable...or is
it?
(didn't find anything about it in doc)
2.theres no such
thing as %unassign
(again there could be but t's not
documented)
3.there's no way to add strings
like:
"ver"+"_0_1"+ ".o" into "ver_0_1.o"
(dito there was not
doc about it...)
(and just another unrelated q - will
nasm ever support assumptions - is it in the near future plans?)
Logged In: NO
(1)
The %UNDEF preprocessor directive operates on
preprocessor constants and single-line macros,
but not multi-line macros. So while it can be
used to undefine %(I)ASSIGNs or %(I)(X)DEFINEs
it can't be used to undefine %(I)MACROs.
Ideally NASM should support %UNDEF as well as
%UNDEFI, and %UNDEFM as well as %UNDEFMI. Plus
a -U as well as a -u command line option, to
match %UNDEF and %UNDEFI, of course.
(2)
As for %UNASSIGN -- no, there is no such pre-
processor directive... but as mentioned above,
you can use %UNDEF. The reason is quite simple:
the difference between %ASSIGNs and %DEFINEs
is that the former, at definition time, must
expand and evaluate to a numeric value -- but
after that the two act identically... which is
why NASM keeps them in the same storage (smac).
That said, it would be a bit tricky to support
both, %UNDEF and %UNASSIGN. In essence, smac
would require a new field, to differ between
%ASSIGNs and %DEFINEs. While this is doable, it
doesn't look all that useful (to me, that is).
(3)
As for string concatenation -- in theory you
should be able to achieve it by using %+ in a
single-line macro. However, in practice I have
not been able to get this to work. I can't seem
to get the parameters substituted before the %+
attempts to concatenate tokens, and I can't
seem to get two strings handled properly in the
same line. I've run into this before, and maybe
it's time to trace this one down for good.
(4)
As for assumptions -- it depends on whether we
are willing to sacrifice one of NASM's original
goals: no clutter, less red tape, etc.
Personally, I am not happy about NASM turning
into a drop-in replacement for MASM or TASM,
with all the downsides of those two assemblers.
But then, it's easy for me to maintain a fork,
which only gets the changes I really want. :-)
Logged In: NO
then i've another, q - is nasm planned to be limmited solely to x86? couldn't
only the opcode tbl, and handle, be changed, to compile for a different
proccessor? is there a group handleing such task, and if so - how can 1 /j
'em? or else - will there ever be one, in the near future?
Logged In: NO
As of writing this NASM is more or less limited to being
an x86 assembler. However, thanks to its modular design
it could be modified to support other architectures.
One would have to write a new instruction database, write
a new assembler and disassembler that know how to use said
new database, write a new parser for the syntax of the
target instruction set, and update the documentation.
In addition the FP handling code would have to be updated,
unless the new architecture is like x87. All of the other
modules should require little or no work.
This may sound trivial. But keep in mind that it's just
meant to be a high-level overview. Adding support for one
or more new target architectures would be a substantial
effort no matter what. As would be testing it.
How likely is it? Well, if someone really needs support
for a new target architecture, and that someone really
thinks that NASM is a good starting point, then he or she
is going to do it. Or pay someone else to do it.
Keep in mind that the development could happen behind
closed doors. And that the resulting work could remain
behind those closed doors forever.
Logged In: NO
hmmm - i'll attempt to explain what i ment by, assume -
i didn't meant
that the syntex is SO importent, in fact,
i don't really care at the
moment.
i had the "org" directive in mind - it'd be much better if -
*
the "org" directive, could be used, more than once (i think that
everybody's familiar with ocassions, where i could've been
usefull).
* "org" works at the moment only for code, it'd be nice, if it
would word, for ds as well.
here's an example, where it could
be usefull - ex.:
a piece of code which relocates itself, would need
to
cahnge both the relative addresses, and code, while
compilation, or else, everything, past the jump will be
meanningless!
/sfa2k
(ohh and btw- about the support for
other processors:
i will check, the possibility, of adding such support
myself -
i was a little frightened to attempt such a thing on my own, and
hoped, that there is a team working on it. since, i'm really basicly, a
begginer - my years, of expirience, could be counted, using one hands
fingers...)
Logged In: NO
Yes, I have had thoughts about ORG, too. It would be nice
to have it work more than once, so you don't have to do the
work manually.
Logged In: NO
What you are looking for is a way to freely change the
offset portion of $. Most assemblers use ORG for that
purpose; however, NASM doesn't provide that capability,
and it does use ORG for a different purpose.
Personally I think that this represents a bad design
choice on the part of NASM, which should be rectified
eventually. Programmers who want total control, _do_
occasionally need the ability to freely change the
offset portion of $. And the vast majority of assembly
programmers _does_ expect to use ORG for that, due to
precedence set by MASM and TASM.
My suggestion is to address this in v1.x, whereas a
command line option and/or assembler directive should
be used to toggle between the ORG interpretations.
However, there is one issue that needs to be resolved
before "multiple ORG support" gets implemented.
Namely we must think about "sparse" versus "non-sparse"
output formats. (Or maybe it's "relocatable" versus
"non-relocatable" -- I don't know yet.)
Is an ORG from A to B, whereas B is greather than A,
merely going to modify the offset portion of $, or is
it also going to emit padding bytes? And should the
value of those padding bytes be programmable?
Logged In: YES
user_id=68913
Regarding Multiple "org"s - the problem is precisely "To Pad
or Not To Pad". For code that gets relocated, the brand-new
"vstart" addition should do what you want(?).
Best,
Frank