Menu
▾
▴
#13 IDEAL mode support
TASM has a great programming mode called IDEAL mode, and I
use it for everything.
If NASM could support IDEAL mode,
then I would switch to NASM.
Thanks in
advance.
P.S.: I will be more than happy to try to compile my
code with NASM and report any errors I get, and would do my best to
provide sample source code that causes the errors (and compiles
okay in TASM).
Logged In: NO
What's so different between TASM ideal and NASM syntax?
I think they are quite similar.
Logged In: NO
What's so different between TASM ideal and NASM syntax?
I think they are quite similar.
Logged In: NO
What's so different between TASM ideal and NASM syntax?
I think they are quite similar.
Logged In: NO
I'm somewhat concerned by the trend of making NASM
support everything TASM does. I mean, if we continue on
this path, then we will eventually have to add everything
MASM does, won't we?
Wouldn't it be better to keep NASM free of that clutter,
and rely on a set of conversion scripts instead?
Another solution I can think of is moving all the TASM or
MASM stuff into separate modules, sort of like additional
preprocessors.
Just curious.
Logged In: YES
user_id=621016
Actually, IDEAL mode has some very significant differences from
MASM mode which make it incompatible unless the "IDEAL" directive
is specified (to enable its usage). The other directive is "MASM" which
switches back to MASM mode.
One of the distinct differences
between IDEAL mode and MASM mode is demonstrated by this short
example of a PROCedure declaration:
; In MASM
mode...
FunctionName PROC
; Code goes
here
FunctionName ENDP
; In IDEAL mode...
PROC
FunctionName
; Code goes here
ENDP
FunctionName
Conversion scripts are a bad idea because the
advantages of IDEAL mode will be lost. Addressing is very clear in IDEAL
mode, thus debugging is much easier, while MASM mode's addressing
is somewhat ambiguous and inconsistent (and more difficult to debug).
Note: The type of debugging I'm referring to is reading the instructions on
a hard copy (printout) of the code.
I really like the idea of adding
modules to support these different syntaxes. With the addition of the
"IDEAL" directive, this would completely avoid any downward
compatibility problems with older code written for NASM, and would
ensure that nothing ever interferes.
I believe it would be very good
for NASM (from a marketshare point of view) to eventually support all
these different modes as it would provide developers with the very best
qualities an assembler could ever possibly have.
Unfortunately
Borland has stopped developing TASM, and management has
completely ignored my requests to speak with me about this -- this worries
me because I wonder if they're treating customers of other products this
way also.
Thanks in advance.
Logged In: NO
Why not convert the TASM code into NASM code, and never look
back?
Logged In: YES
user_id=621016
Why not support IDEAL mode? Everyone claims compatibility with
TASM, but it's obviously not true.
My original question was
regarding IDEAL mode support. I'm not interested in converting my code
for a number of reasons (one of which is that I have far too much code to
convert).
Are you folks really interested in having people switch
to and use NASM regularly? If so, then adding IDEAL support (and even
MASM support) will really help in that regard. I believe that Apache, for
example, is largely successful because they implement new features
suggested by their users.
Logged In: NO
Don't get me wrong -- I am not fundamentally against
adding TASM and MASM support to NASM. I would be
foolish not to acknowledge the potential benefits.
However, at the same time I am concerned that doing
so may force us to give up one of NASM's original goals:
less red tape, no contradictions, no quirks -- in short: a
cleaner assembler than either TASM or MASM. (Would
it be heresy to add support for ORG which can be used
more than once, both forwards and backwards? :-)
That's why I suggested external conversion scripts, or
built-in but optional modular support for TASM or MASM
code, instead of sneaking in bits and pieces.
I think one of the first things we should establish is the
level of TASM and MASM support that is desired. I mean,
would NASM be turned into a drop-in replacement for the
two? Or would we just add enough support, so that most
code will assemble, after reasonable manual clean-up?
Another item would be the prioritization versus all those
other things on NASM's to-do list. Especially all the bugs
that just seem to be piling up these days.
Maybe v0.99 should mark a feature freeze, v1.00 should
fix the majority of known issues, and v1.xx should get the
big chunks of new stuff, which would then become final
in something like v2.00? Just a thought.
Logged In: YES
user_id=621016
Thanks for that.
I think that there is a misunderstanding here with
regards to the cleanliness of NASM vs. adding support for the other
assemblers...
Firstly, having support for TASM and other
assembers as additional modules is a really good idea. For those who
don't have a need for these modules, they can simply be
omitted.
With regards to polluting the NASM instruction set, I
suspect you aren't aware of how TASM, MASM, and others would have to
be implemented anyway. That is, the TASM instructions (such as ORG)
would only work while TASM's IDEAL or MASM modes are
active.
Here's my suggestion: Some new
directives...
NASM ; Switch to NASM mode (also the
default)
IDEAL ; Switch to TASM's IDEAL mode
MASM ; Switch
to Microsoft Assembler mode
QUIRKS ; Switch to Microsoft
Assembler's quirky mode
OPTASM ; Switch to OPTASM
mode
Note that I include MASM, QUIRKS, and OPTASM to
demonstrate different assembler support. All I'm concerned with is
IDEAL mode since I never program any other assemblers.
To
reduce directive pollution, the above directives could actually be
parameters on a "MODE" directive. For example, to switch to IDEAL
mode one could use: MODE IDEAL
It's important to be aware that
any "NASMisms" not be in effect when a different assembler mode is
active, and the same with all the others.
The above approach will
actually make it extremely easy for developers to slowly convert their
code, one function or a few lines at a time, to a different assembler, such
as NASM. As for those who wish to stick with what they're more familiar
with, they'll also be accomodated.
Yes, the modular design
would definitely be a smart move.
With regards to bugs, I believe
that NASM has a very serious bug in that it's TASM compatibility is totally
broken at this time since IDEAL mode isn't supported. So, yeah, those
bugs really do need to be fixed.
Logged In: NO
I see. We would end up with a generic ASM core, which
has modular support for NASM, TASM, MASM, etc. syntax.
Uhm, have you already looked at YASM?
I know, I know -- that's heresy. :)
But I am serious. I have spent quite some time staring
at the NASM source code, and I don't think that it is
the best starting point for this sort of idea -- while
it is modular, the code which handles the actual syntax
is spread all over the place. :-(
In fact, that's one reason for why I suggested the use
of conversion scripts earlier during this discussion.
Mmh. [Scratching my head.]
I would like to take a step back for a second, to just
IDEAL mode support. Maybe we can come up with sort of a
diff between NASM syntax and TASM's IDEAL mode syntax?
Having that would help make the right decision, I think.
Logged In: YES
user_id=621016
Yeah, I've tried YASM and many others, but so far none of them can
process my IDEAL mode code:
http://asm.8x.ca/tools/assemblers.html
I'm really glad you're
interested in looking at the differences. In addition to recommending a
book that explains the differences between MASM mode and TASM's
IDEAL mode:
Turbo Assembler Bible by Gary Syck
1991
The Waite Group, Inc.
ISBN 0-672-22716-9
As for NASM
mode, I'm not familiar with its differences at all, but perhaps we should
start with these:
- Procedure declaration and local variable
declaration
- Addressing local variables (stack data) and global
variables (in the DATA segment/section)
Thanks in advance,
and by the way, I'm very positive about NASM right now because of your
response -- I'm really looking forward to further discussion with you on this
as I believe that adding MASM and TASM support in a modular fashion
will make NASM the very best assembler in existence.
Logged In: NO
Mmh. I guess I will have to dig out my old MASM and TASM
manuals after all. I was hoping to avoid that, since they
sit at the very back and very bottom of my closet. So it
is gonna take a while... definitely until next year. :-)
As for those starting points you mentioned -- NASM's core
has no support for procedures or local variables. All it
has are macro and label support. While they may look very
simple, they are really powerful when used properly.
One thing we'll definitely run up against is NASM's lack
of support for MASM-style memory references. For example:
S1 segment
my_var db 0 ; NASM accepts this, but pefers a ":"
S1 ends
S2 segment
assume DS:S1 ; NASM puts this burden onto the user
mov my_var,1 ; NASM requires "mov BYTE [my_var],1"
mov my_var,ax ; NASM won't tell you that you used DB
S2 ends
end
Personally I think that NASM's inferior-looking support in
this area is one of the features which makes it superior,
because it forces the user to think, and because it results
in more readable, explicit, and x86-like source code. (At
first I hated this part, but by now I have come to love it.
It's one of the main reasons for why I like to use NASM.)
Anyway.
Lets try to write down some IDEAL mode stuff. Then we can
figure out the right course of action.
Oh, and yes, it would be really great if other NASM users
and/or developers could chime in in this.
Logged In: YES
user_id=621016
Segment declarations in IDEAL mode take the directive first, followed by
the label:
segment S1
my_var db 0 ; TASM accepts
this
ends S1
Personally, I never use the ASSUME directive
because I'm only writing 80386+ protected mode code anyway, so I'd put
ASSUME as a lower priority unless there are some IDEAL mode
developers who need it.
Perhaps the NASM interpreter should
be moved into a separate module for version 2, and then other modules
can be added more easily -- I've been thinking about the point someone
(you?) made earlier that the NASM Syntax interpretation is scattered
throughout the program. Obviously modularizing this would probably
make it a lot easier to debug as well. Apache [web server] has done very
well at being modular, and I've found that planning my own projects in this
way really does make life easier in the long run as well (and I've developed
few fair sized projects in assembler in the private sector).
Logged In: NO
Well, NASM already supports "segment S1". However, it does
not really have a concept of explicitly ending a segment.
One could make an ENDS macro that enters absolute space --
this would catch run-away code and data, but not run-away
labels. In other words: it would still be useful, since
run-away code and data are harmful, while labels are not.
As for ASSUME, or labels that remember the size which was
given at the time of their definition so that an error can
be generated if there's a size mismatch at the time of their
invocation -- those would be harder. NASM is explicitly not
tracking this sort of information. (IMO a good thing.)
Logged In: NO
actually i think that the idea of including a suport for syntexs of other
compilers is a really good one - but as others have said, it won't be usefull for
all the users. therefore the best thing to do in my opinion is to (ofcourse,
after a complete saperation, again as otheres mantioned - to ease the
debugging process etc) simpley combine, both ideas: to have these
pointing directives, according to which, nasm will reffer, to the syntex,
file for ex -
NASM
somecode
MASM
somecode
during
the first etap, it'll use a file such as 'nasm.stx',
and during the second,
a 'masm.stx'.
and by default use nasm syntex (unless specified
otherwise, for ex in the cmd line like : "-stx masm" or
something...).
this will cover, "all" of the topics mentioned:
-no
convertion, to take a prog originally targeted, for an another compiler to
compile in nasm.
-one'll be able to use the advantaged, of all the
supported, syntexes..
-one, won't need to d/l and have support for
syntexes, which he/she doesn't need...
.
.
.
(ofcourse if
we go this way it'd be reall nice to have support for other processors like
arm mt and others...
but again this thing can go and go - ppl might ask to
make support for new processor to be optional...or will
they...nm...)
/sfa2k
Logged In: YES
user_id=621016
Yes, separate first, then add IDEAL and MASM support. Later on other
compiler formats could be added, such as WASM or OPTASM,
provided there's interest in them, the point being that more modes can be
added in a modular fashion thus greatly enhancing the power of
NASM.
If NASM can handle these three modes, NASM (the
default, obviously), TASM/IDEAL, and MASM, I'm certain that it will then
take the assembler programming industry by storm and the
Borland/Microsoft assembler followings will dwindle down to almost
nothing -- another victory for Open Source!
Logged In: NO
Why does NASM need TASM support at all?
I mean, why don't you just use TASM for your TASM code?
Logged In: YES
user_id=621016
Because TASM doesn't support the latest CPUs, and Borland has been
ignoring requests from various developers to add support and fix some
very old bugs.
Many developers are desparate for an alternative,
and some are also afraid that Borland's going to run all of its products into
the ground with this crappy attitude.
Logged In: NO
So why not use TASM for existing code, but NASM for
newly written code, and then link things together?
Granted, this won't help for those "very old TASM
bugs" you cited... but clearly you have managed to
work around those until now, haven't you? :)
Mmh. Maybe what's really needed is the equivalent
to ANSI C, but for x86 (and x86-64) assembly. After
all this platform is used widely...
And hey, I don't mind if NASM learns how to deal
with TASM code, as long as that remains optional.
However, I'm not yet convinced that NASM is the
best starting point for the "uber-assembler". It
contains a lot of legacy junk, and -- despite a
large user base -- has never undergone any real
testing effort. (Just look at the bugs we keep
finding in the instruction database, for example.)
Logged In: YES
user_id=621016
All I'm asking for is IDEAL mode support in NASM, and to have it
implemented in an optional fashion so as not to break compatibility with
older versions of NASM. That is, if the IDEAL keyword is not specified,
then the IDEAL mode stuff simply won't come into play.
The
problem with mixing code from two different assemblers is that I'll be
writing code for two different styles of assemblers, and I need to stick to
IDEAL mode.
It seems that a lot of people around here are
interested in finding reasons NOT to enhance NASM, and it's getting a bit
frustrating -- have I misunderstood what open source is there for or is the
NASM project dying? My experience with other open source projects
has been that people are very happy to add new features (e.g., Apache
Web Server, PostgreSQL, &c, all striving to be the best). I was really
hoping that NASM would be no different.
With regards to testing,
I'll be happy to do plenty of it provided IDEAL mode is added. After all, I am
looking for another assembler.
Logged In: NO
> It seems that a lot of people around here are
> interested in finding reasons NOT to enhance
> NASM, and it's getting a bit frustrating --
> have I misunderstood what open source is there
> for or is the NASM project dying?
And what is your reason for not doing it yourself?
Or are you just another "open source parasite"? :-)
Logged In: YES
user_id=621016
I'm not a C/C++ programmer, and I'm certainly not a parasite. I am still
disappointed though in the negativity that seem to eminate from certain
open source groups. When I compare this to the PostgreSQL or Apache
groups, I find that PostgreSQL and Apache folks are open to
suggestions, but this group seems intent on finding reasons NOT to add
new features or improve the product. Your latest attack only further
exemplifies this attitude, and although you may not be a representative
of the group you are setting a rather destructive tone -- do you work for
Microsoft?
Logged In: NO
Hey, so far your request for TASM support
hasn't been rejected; it merely stirred
an interesting discussion, during which a
bunch of good questions and suggestions
were brought up. For example:
Is NASM the best starting point?
Do we want to sacrifice some NASM goals?
Are there enough actual developers?
Wouldn't modular syntax support be nice?
Personally I like the idea of having an ASM
core which can be outfitted with MASM, TASM,
NASM, etc. behavior. But at the same time I
am realistic enough to acknowledge that NASM
lacks the developers to pull this off any
time soon. And that pointing to other more
successful open source projects isn't going
to kick start NASM development.
It's no shame if you don't know C. Maybe
you can contribute in a different way. For
example, it would be really helpful if we
had a complete/comprehensive/exhaustive list
of "TASM syntax things". Something way more
detailed than a mere list of "I'm always
using this directive" or "that feature".
That would really help.
Logged In: YES
user_id=621016
I didn't take kindly to being called a "parasite." Of course you're right
that comparing to other projects isn't generally fair, but when it comes
to attitude it's a different matter entirely; Instead of name calling,
simply pointing out (as you just did) that there may not be enough
developers would have been a much better approach.
I definitely
don't expect immediate results since I realize that I'm not dealing with a
commercial organization that staffs developers to meet customer
demands.
With regards to NASM's goals, what are they?
My own
contributions would definitely be in testing the IDEAL mode support, and
providing detailed suggestions (and direction where appropriate) for
improving/correcting the implementation.
As for a
completely/exhaustive list, I'd be happy to work on this if there was a
firm commitment from this NASM group to implement IDEAL mode support
since I could start by prioritizing which features should come first. Of
course I also wonder if my efforts might be duplicating what has already
been done in the following book which already goes into tremendous detail
about IDEAL mode (complete with examples):
The Waite Group's Turbo
Assembler Bible
by Gary Syck
SAMS Publishing 1991
ISBN: 0-672-22716-
9
LCCCN: 90-62944
Thanks a lot for your response. You've restored my
optimism in the NASM community. =)