masm.exe
Chris Hargrove
>PLEASE.....
>where I can find masm.exe
You buy it, like you're supposed to.
--------------------------------------------------------------------------------
Chris Hargrove (aka Kiwidog / Terraformer) | T E R R A F O R M E R
<kiw...@vt.edu> | 1995
"The virtual planet is the ultimate colony" | The USA demo team with no limits.
--------------------------------------------------------------------------------
Jason Herbers
: manu <votre_nom_d'utili...@worldnet.net> wrote:
:
: >PLEASE.....
: >where I can find masm.exe
:
: You buy it, like you're supposed to.
MASM stands for Macro ASsMebler, which is made by Microsoft
Corporations. However I strongly recommend you buy TASM instead
considering that it has more powerful features yet is 100% compatiable
with MASM code. You're only ripping yourself off if you get MASM.
Marvin Herbold
Fledging PC Game Programmer
Joel Rubin
they've called it "MASM.EXE" since 5.1 or so. Actually, 5.1 may be good enough
for most purposes. How many people actually use the special features of TASM
or (even fewer) MASM 6+? On the other hand, a lot of people use the simplified
segmentation introduced in 5.0 or so.
I think 5.1 or something like that was on one of those $15 beta MSDN disks
back a few years ago as part of some other package. So, it might be possible
that it is downloadable somewhere legitimate. (not Joe's Pirate BBS) It is
probably available cheap from some place that buys from bankruptcy sales or
something like that.
Of course, there are always shareware and freeware assemblers.
Jason Herbers
> In article <46s1s2$2...@news4.digex.net>, smo...@access5.digex.net says...
> >
> >Chris Hargrove (kiw...@mail.vt.edu) wrote:
> >: manu <votre_nom_d'utili...@worldnet.net> wrote:
> >:
> >: >PLEASE.....
> >: >where I can find masm.exe
> >:
> >: You buy it, like you're supposed to.
> >
> > MASM stands for Macro ASsMebler, which is made by Microsoft
> >Corporations. However I strongly recommend you buy TASM instead
> >considering that it has more powerful features yet is 100% compatiable
> >with MASM code. You're only ripping yourself off if you get MASM.
> >
> > Marvin Herbold
> > Fledging PC Game Programmer
> >
> Actually, the current version of MASM is "ml.exe", isn't it? I don't think
> they've called it "MASM.EXE" since 5.1 or so. Actually, 5.1 may be good enough
> for most purposes. How many people actually use the special features of TASM
> or (even fewer) MASM 6+? On the other hand, a lot of people use the simplified
> segmentation introduced in 5.0 or so.
The original poster was probably hoping to get an older version of MASM
free. This is not possible, there isn't a statue of limitations on
paying for a product.
Also, I use almost every feature that TASM has to offer. I especially like
the IDEAL mode since everything makes much more sense in that mode.
Since you're probably paying the same amount for TASM as you are for
MASM, why not get TASM and get the best of both worlds? TASM can emulate
MASM all the way, even using the QUIRKS directive to simulate some of the
bugs inherent in MASM. You also get the debugger, which is okay in my
opinion. If you want a really awesome debugger, I say go with no less
than Watcom's debugger, because it really rocks.
> I think 5.1 or something like that was on one of those $15 beta MSDN disks
> back a few years ago as part of some other package. So, it might be possible
> that it is downloadable somewhere legitimate. (not Joe's Pirate BBS) It is
> probably available cheap from some place that buys from bankruptcy sales or
> something like that.
I seriously doubt that. Remember this is Microsoft we're talking
about. Them giving stuff away free? HAHAHAHAHAHAHA... good joke.
> Of course, there are always shareware and freeware assemblers.
Right. I recommend A86 as a good starting point.
Glen Blankenship
> MASM stands for Macro ASsMebler, which is made by Microsoft
> Corporations. However I strongly recommend you buy TASM instead
> considering that it has more powerful features yet is 100% compatiable
> with MASM code. You're only ripping yourself off if you get MASM.
I'd take that "100% compatible with MASM code" with a rather large grain
of salt, if I were you.
First of all, it's only compatible with MASM 5.1 code. Now, MASM 5.1 is a
full-featured assembler, but a lot of code being written today (especially
code written for Windows) is written to take advantage of MASM 6.x's
features, particuarly the high-level flow-control constructs and the
procedure prototypes and invocations. Emulating such things in TASM takes
a lot of code rewriting or a lot of macro building.
Secondly, I'll admit that I haven't tested TASM for MASM compatibility
since TASM 2.0, but it made the same claims for MASM 5.1 compatibility
that v4.0 does (including the "right down to the bugs" brag about the
useless-but-much-hyped QUIRKS directive), and it was simply not true. All
too frequently, it would generate spurious error messages for perfectlyy
correct MASM code, assemble code incorrectly, refuse to assemble code that
had assembled properly in MASM, and assemble without complaint code that
would have caused errors in MASM, frequently producing odd and unintended
effects as a result.
That last bit was a particular nuisance. Because TASM allowed many of the
syntactic constructs from its "IDEAL" mode in "MASM-compatible" mode, and
because its syntax checking in MASM mode was horribly sloppy, the only
way to tell if code assembled in "MASM-compatible" mode really *was*
MASM-compatible was to actually assemble it in MASM and then do binary
comparisons of the linked executables.
Finally, its 32-bit support was so buggy as to be completely useless.
The high-level language interface features would always assemble
16-bit code, even inside 32-bit segments - from code that assembled
perfect 32-bit procedures in MASM 5.1.
Now, it's entirely possible that they've cleaned up some of those bugs in
the intervening two releases (I certainly hope they've improved the
32-bit support), but I was hearing the same "100% MASM-compatible, right
down to the bugs" hype from Borland enthusiasts back then that we're
hearing now.
If MASM compatibility is important to you, you owe it to yourself to do
some serious testing before you take anyone's word for it.
---
Glen Blankenship
obo...@netcom.com
BIOS...@rahul.net
Jason Herbers <smo...@access5.digex.net> wrote:
>On Fri, 27 Oct 1995, Joel Rubin wrote:
>> In article <46s1s2$2...@news4.digex.net>, smo...@access5.digex.net says...
>> >
>> >Chris Hargrove (kiw...@mail.vt.edu) wrote:
>> >: manu <votre_nom_d'utili...@worldnet.net> wrote:
>> >:
>MASM all the way, even using the QUIRKS directive to simulate some of the
Well, I wouldn't say 100% emulation of MASM (ML). I've see TASM insert
it's own "quirks" in "quirky-MASM" code.
>bugs inherent in MASM. You also get the debugger, which is okay in my
>opinion. If you want a really awesome debugger, I say go with no less
You get CodeView with MASM (ML). (whoopie).
>> I think 5.1 or something like that was on one of those $15 beta MSDN disks
>> back a few years ago as part of some other package. So, it might be possible
MASM 5.1 is included on the Windows SDK or DDK disks... I don't remember
which. It also is included if you subscribe to the MSDN.
Jason Herbers
: Now, it's entirely possible that they've cleaned up some of those bugs in
: 32-bit support), but I was hearing the same "100% MASM-compatible, right
: down to the bugs" hype from Borland enthusiasts back then that we're
: hearing now.
Right now I'm using TASM 4.5 alongside with Watcom C/C++ 10.5, and the
32 bit code/support is certainly not causing me any trouble at all. I
guess TASM did go through a big change from 2.0 to 4.5.
: If MASM compatibility is important to you, you owe it to yourself to do
: some serious testing before you take anyone's word for it.
It is. Most of the ASM code freely availiable is meant for MASM 5.1,
and I have had no trouble plugging it into TASM without any source
editing. And I have compiled quite a few. Can you give me an example of
some MASM 5.1 code that you think TASM will fail at? I'd really like to
try it with my TASM 4.5 and see what happens.
And of course, when we are talking about software, we have to take
EVERYTHING with a grain of salt. There's no such thing as perfect code
because there is no such thing as perfect machines. You can't have
perfect code without perfect machines which have yet to come.
Jason Herbers
: In article <Pine.SUN.3.91.951028...@access5.digex.net>,
: Jason Herbers <smo...@access5.digex.net> wrote:
: >On Fri, 27 Oct 1995, Joel Rubin wrote:
: >> In article <46s1s2$2...@news4.digex.net>, smo...@access5.digex.net says...
: >> >
: >> >Chris Hargrove (kiw...@mail.vt.edu) wrote:
: >> >: manu <votre_nom_d'utili...@worldnet.net> wrote:
: >> >:
: >MASM, why not get TASM and get the best of both worlds? TASM can emulate
: >MASM all the way, even using the QUIRKS directive to simulate some of the
:
: Well, I wouldn't say 100% emulation of MASM (ML). I've see TASM insert
: it's own "quirks" in "quirky-MASM" code.
Heh. What version of TASM are you referring to? I've had no problems
compiling MASM code in version 4.5 of TASM. Maybe by luck I've simply
not come across any MASM code that'll fail in TASM.
: >bugs inherent in MASM. You also get the debugger, which is okay in my
: >opinion. If you want a really awesome debugger, I say go with no less
:
: You get CodeView with MASM (ML). (whoopie).
I think the best debugger I've ever come across is from Watcom called
WD. I'll admit that Borland did a lame job in their debugger TD. I
mean, how the hell can anyone forget to return allocated memory to the OS
when exiting the debugger? Try this: Write some code to allocate memory
using DOS INT 21h calls, use TD to step through the code, but exit the
debugger completely right after it allocates some memory. Now at the DOS
prompt, type MEM. GASP! Where'd your memory go? Check out MEM /D /P
and you'll see where it went. Really pathetic, in my opinion. Aren't
they supposed to TEST the software they release?
: >> I think 5.1 or something like that was on one of those $15 beta MSDN disks
: >> back a few years ago as part of some other package. So, it might be possible
:
: MASM 5.1 is included on the Windows SDK or DDK disks... I don't remember
: which. It also is included if you subscribe to the MSDN.
That's OK, I guess. I'm starting to see more and more code being
written in TASM. So what if you have MASM? You're stuck. At least with
TASM you'll still have some change of fiddling with the directives until
TASM does it right (I'm only guessing, I've never had to fiddle with
anything).
Barry B. Brey
--
Very truly yours,
Barry B. Brey
Professor of Electronic Engineering Technology
DeVry Institute of Technology
1350 Alum Creek Drive
Columbus, Ohio 43209
Look at my webpage below:
http://www.ee.net/bbrey/ <==main page
or
http://www.geopages.com/TimesSquare/1726/ <==mirror
barrym
: Jason Herbers (smo...@access5.digex.net) wrote:
: > MASM stands for Macro ASsMebler, which is made by Microsoft
: > Corporations. However I strongly recommend you buy TASM instead
: > considering that it has more powerful features yet is 100% compatiable
: > with MASM code. You're only ripping yourself off if you get MASM.
: I'd take that "100% compatible with MASM code" with a rather large grain
: of salt, if I were you.
: First of all, it's only compatible with MASM 5.1 code. Now, MASM 5.1 is a
: full-featured assembler, but a lot of code being written today (especially
: code written for Windows) is written to take advantage of MASM 6.x's
: features, particuarly the high-level flow-control constructs and the
: procedure prototypes and invocations. Emulating such things in TASM takes
: a lot of code rewriting or a lot of macro building.
: Secondly, I'll admit that I haven't tested TASM for MASM compatibility
: since TASM 2.0, but it made the same claims for MASM 5.1 compatibility
: that v4.0 does (including the "right down to the bugs" brag about the
: useless-but-much-hyped QUIRKS directive), and it was simply not true. All
: too frequently, it would generate spurious error messages for perfectlyy
: correct MASM code, assemble code incorrectly, refuse to assemble code that
: had assembled properly in MASM, and assemble without complaint code that
: would have caused errors in MASM, frequently producing odd and unintended
: effects as a result.
: That last bit was a particular nuisance. Because TASM allowed many of the
: syntactic constructs from its "IDEAL" mode in "MASM-compatible" mode, and
: because its syntax checking in MASM mode was horribly sloppy, the only
: way to tell if code assembled in "MASM-compatible" mode really *was*
: MASM-compatible was to actually assemble it in MASM and then do binary
: comparisons of the linked executables.
: Finally, its 32-bit support was so buggy as to be completely useless.
: The high-level language interface features would always assemble
: 16-bit code, even inside 32-bit segments - from code that assembled
: perfect 32-bit procedures in MASM 5.1.
: Now, it's entirely possible that they've cleaned up some of those bugs in
: the intervening two releases (I certainly hope they've improved the
: 32-bit support), but I was hearing the same "100% MASM-compatible, right
: down to the bugs" hype from Borland enthusiasts back then that we're
: hearing now.
: If MASM compatibility is important to you, you owe it to yourself to do
: some serious testing before you take anyone's word for it.
: ---
: Glen Blankenship
: obo...@netcom.com
I've had a lot of the same problems with Tasm that you describe. But I
still prefer it to Masm. They both have plenty of bugs. When I was
doing assembly at work, I found that I usualy was forced to use Masm for
compatibility reasons. Now that I don't do much assembly at work, and
most of what I do is my own stuff at home (hobby stuff), I can use Tasm
and just not care.
I think there is one other consideration that someone learning assembler
should consider, though. Masm is the standard and if he plans on doing
commercial work, he will be somewhat better off if he's comfortable
with Masm since that's what most businesses use.
Barry
barrym
: Glen Blankenship (obo...@netcom.com) wrote:
: : Now, it's entirely possible that they've cleaned up some of those bugs in
: : 32-bit support), but I was hearing the same "100% MASM-compatible, right
: : down to the bugs" hype from Borland enthusiasts back then that we're
: : hearing now.
: Right now I'm using TASM 4.5 alongside with Watcom C/C++ 10.5, and the
: 32 bit code/support is certainly not causing me any trouble at all. I
: guess TASM did go through a big change from 2.0 to 4.5.
: : If MASM compatibility is important to you, you owe it to yourself to do
: : some serious testing before you take anyone's word for it.
: It is. Most of the ASM code freely availiable is meant for MASM 5.1,
: and I have had no trouble plugging it into TASM without any source
: editing. And I have compiled quite a few. Can you give me an example of
: some MASM 5.1 code that you think TASM will fail at? I'd really like to
: try it with my TASM 4.5 and see what happens.
About 4 months ago someone at my office downloaded Masm 5.1 source for
a routine to intercept certain interrupts within some Novel driver.
The file was from Novell. We assembled it with Tasm because it was in
my path. I don't remember what version it was. Probably 3.5.
It crashed. I tried re-assembling it with every combination of switches
I could think of. No luck. It assembled with no errors each time.
I used Masm 5.1 and it ran perfectly. I didn't look into the problem.
It's happened before. This is only the most recent.
90% of the time it really doesn't matter. But sometemes it does.
: And of course, when we are talking about software, we have to take
: EVERYTHING with a grain of salt. There's no such thing as perfect code
: because there is no such thing as perfect machines. You can't have
: perfect code without perfect machines which have yet to come.
: Marvin Herbold
: Fledging PC Game Programmer
Pixelated!
>In article <30945E...@moonware.dgsys.com>,
> Raymond Moon <ray...@moonware.dgsys.com> wrote:
>>I thought that TASM is compatible only with MASM 5.1. MASM 6.x has
>>introduced many enhancements. Some of these I have grown to need.
Mostly, but perhaps not.
>>Examples are:
>>- Predefined Symbols such as @Model which allows me to put in conditional
>>assembly to memory model specific code. I write a procedure for all memory
>>models so that I can reuse procedures in follow-on projects.
TASM has this.
>>- Structures now can be nested. This allows me to use algorithms I learned
>>in C much easier.
I dunno. DOn't think so, tho.
>>- Unions just as in C.
Again, these exist in TASM.
>>- Multiple-Line Initializers for all variables. This makes reading and
>>documentation much simpler than having a long initializer on one line.
Via the { } operator, rright? Same in TASM.
>>- Externdef which allows me to put global data declarations within a include
>>file but only actual references from the code are placed into the .obj file.
I think TASM has these; I'd have to dig out my ref manuals.
>>- Most importantly are the improvements in the macro functionality. I have
>>rather complex macros that allow me to use constants, memory variables,
>>references to memory varialble, registers or some combinations of all in
>>macros and the macros sort it out. Again, the macros take care of issuing
>>the correct code for the memory model. This is a GREAT convenience.
The TASM macro facility is pretty powerful; but, not having MASM, I couldn't
compare the two. I will say that I find TASM's referring to grouped segments
"properly" (my definition--meaning it calculates offsets relative to the group,
not the individual segment, makes much more sense.)
>>I do hope that TASM has comparable capabilities. I only wish that there was
>>a standards committee, but I guess that would be hoping for too much.
Heh. Not while 'ol Bill Gates has his way. Besides, with Microsoft canning
all it's asm people, it won't be long before MASM vanishes, I'll bet. Then
you'll be stuck with TASM. :)
>Let me add one to that:
>-LOCAL LABELS (thank God) that is, labels local to the procedure rather
> than a
>file. (It is very tiring coming up with unique names for similar tasks. e.g.
>EXIT, NEXT...)
Please. TASM has had these since at least version 2. And MASM has had 'em
since, what, 5.0? Earlier?
Personally, IDEAL mode (IMNSHO) is sooo much better. And let's just get it
right out on the floor now--stuff like bx[3] sucks. Why's it so hard to
use [bx+3] instead? :) :)
--
Richard Cooley Extraordinaire | Linux Linux Linux | My opinions, not MIT's.
pi...@gnu.ai.mit.edu | rcoo...@dgl.ssc.mass.edu | pi...@usa1.com
Daisemi'in rhhaensuriuu meillunsiateve rh'e Mnhei'sahe yie ahr'en:
Mnahe afw'ein qiuu; rh'e hweithnaef mrht Heis'he ehl'ein qiuu.
BIOS...@rahul.net
Pixelated! <pi...@gnu.ai.mit.edu> wrote:
>In article <4757l7$b...@news.gate.net>, William Hutto <bhu...@gate.net> wrote:
>>In article <30945E...@moonware.dgsys.com>,
>> Raymond Moon <ray...@moonware.dgsys.com> wrote:
>
>
>Heh. Not while 'ol Bill Gates has his way. Besides, with Microsoft canning
>all it's asm people, it won't be long before MASM vanishes, I'll bet. Then
>you'll be stuck with TASM. :)
What makes you think Microsoft is canning all their Asm people? Seen much
of their code? Might be surprised at how much of it is done with MASM.
>
>Personally, IDEAL mode (IMNSHO) is sooo much better. And let's just get it
>right out on the floor now--stuff like bx[3] sucks. Why's it so hard to
>use [bx+3] instead? :) :)
I agree, and I use the + method too. But, bx[3] is more "high level"ish,
for those who choose not to roll in the dirt...
jASMin C. Blanchette
They are simply not qualified in compiler or assmembler conceptiomn... Borland is beetter,
that's what I think.
And Borland catches errors that MS never see, even in MASM mode.
William Hutto
bar...@starbase.neosoft.com (barrym) wrote:
>Pixelated! (pi...@gnu.ai.mit.edu) wrote:
>
>: >Let me add one to that:
>: >-LOCAL LABELS (thank God) that is, labels local to the procedure rather
>: > than a
>: >file. (It is very tiring coming up with unique names for similar tasks.
e.g.
>: >EXIT, NEXT...)
>
>: Please. TASM has had these since at least version 2. And MASM has had 'em
>: since, what, 5.0? Earlier?
>
>either 1.5 or 2.0, but whichever it was, it was after Masm had them.
>Tasm did them better, in my opinion, but the difference isn't important.
>
>Barry
---------------------------------SOURCE--------------------------------------
DOSSEG
model small
stack
code
proc1 proc
mov ax,@data
mov ds,ax
nop
nop
call proc2
jmp JMP1
nop
JMP1:
mov ah,4Ch
int 21h
proc1 endp
proc2 proc
nop
nop
jmp JMP1
nop
JMP1:
nop
ret
proc2 endp
end proc1
-------------------------------LISTING TO FOLLOW---------------------------
Microsoft (R) Macro Assembler Version 5.10 11/3/95 21:16:20
Page 1-1
JMP1:
test.ASM(26): error A2004: Redefinition of symbol
Microsoft (R) Macro Assembler Version 5.10 11/3/95 21:16:20
Page 1-1
1 DOSSEG
2 .model small
3
4 .stack
5
6 .code
7
8 0000 proc1 proc
9 0000 B8 ---- R mov ax,@data
10 0003 8E D8 mov ds,ax
11 0005 90 nop
12 0006 90 nop
13 0007 E8 0012 R call proc2
14 000A EB 02 90 jmp JMP1
test.ASM(14): error A2026: Reference to multidefined symbol
15 000D 90 nop
16 JMP1:
test.ASM(16): error A2005: Symbol is multidefined: JMP1
17 000E B4 4C mov ah,4Ch
18 0010 CD 21 int 21h
19 0012 proc1 endp
20
21 0012 proc2 proc
22 0012 90 nop
23 0013 90 nop
24 0014 EB F8 jmp JMP1
test.ASM(24): error A2026: Reference to multidefined symbol
25 0016 90 nop
26 JMP1:
test.ASM(26): error A2005: Symbol is multidefined: JMP1
27 0017 90 nop
28 0018 C3 ret
29 0019 proc2 endp
30
31 end proc1
Microsoft (R) Macro Assembler Version 5.10 11/3/95 21:16:20
Symbols-1
Segments and Groups:
N a m e Length Align Combine Class
DGROUP . . . . . . . . . . . . . GROUP
_DATA . . . . . . . . . . . . 0000 WORD PUBLIC 'DATA'
STACK . . . . . . . . . . . . 0400 PARA STACK 'STACK'
_TEXT . . . . . . . . . . . . . 0019 WORD PUBLIC 'CODE'
Symbols:
N a m e Type Value Attr
JMP1 . . . . . . . . . . . . . . L NEAR 000E _TEXT
PROC1 . . . . . . . . . . . . . N PROC 0000 _TEXT Length = 0012
PROC2 . . . . . . . . . . . . . N PROC 0012 _TEXT Length = 0007
@CODE . . . . . . . . . . . . . TEXT _TEXT
@CODESIZE . . . . . . . . . . . TEXT 0
@CPU . . . . . . . . . . . . . . TEXT 0101h
@DATASIZE . . . . . . . . . . . TEXT 0
@FILENAME . . . . . . . . . . . TEXT test
@VERSION . . . . . . . . . . . . TEXT 510
31 Source Lines
31 Total Lines
20 Symbols
47178 + 194898 Bytes symbol space free
0 Warning Errors
5 Severe Errors
Pixelated!
>>Masm had local labels in 5.0 or 5.1, I forget which. Tasm got them in
> jmp JMP1
jmp @@JMP1
> nop
>JMP1:
@@JMP1:
[snip]
> jmp JMP1
jmp @@JMP1:
> nop
>JMP1:
@@JMP1:
1) Make these changes.
2) recompile your program.
3) Read the manual to find out what a "local label" is.
4) Post the revised listing file, and explain to everyone how you
feel foolish for posting without a clear understanding of what we
meant. :)
(sorry if that sounds kind of rude. THis wasn't meant as a flame.)
den...@netcom.com
are and how refined your opinions are, but, now to answer the original
posting: I believe that Microsft DID Make a version (5.1?) of their Macro
Assembler freely available to the public on their ftp server. This was
some months ago, and I have no idea if this is still the case. I may be
talking through my hat on this but it is honestly something I seem to
remember. Maybe a check through ftp.microsft.com is worth the original
poster's time?
Either way, good luck.
Raymond Moon
>
> In article <479c5k$h...@life.ai.mit.edu>,
> Pixelated! <pi...@gnu.ai.mit.edu> wrote:
wrote:
> >Heh. Not while 'ol Bill Gates has his way. Besides, with Microsoft
canning
> >all it's asm people, it won't be long before MASM vanishes, I'll bet.
Then
> >you'll be stuck with TASM. :)
>
> What makes you think Microsoft is canning all their Asm people? Seen much
> of their code? Might be surprised at how much of it is done with MASM.
> >
I am reading "Networking Windows NT 3.51" by John D. Ruley. John Ruley
states in Chapter One that some critical sections of Windows NT 3.5 were
written in assembly language. It appears that Bill Gates isn't canning all
of his assembly language people.
Dr S.J. Harris
>In article <47ep5p$h...@life.ai.mit.edu>,
> pi...@gnu.ai.mit.edu (Pixelated!) wrote:
>>In article <47efck$r...@news.gate.net>, William Hutto <bhu...@gate.net> wrote:
>>>>Masm had local labels in 5.0 or 5.1, I forget which. Tasm got them in
>> ^^^^^ ^^^^^^
[extracted]
>Gee, I seem to constantly have to defend myself. Giving you every benefit of
>the doubt I dug out my old 5.1 manual and here's about all it had to say on
>labels:
>
>page 121
>
>A near label can appear on a line by itself or on a line with an instruction.
>The same label name can be used in different modules as long as each label is
^^^^^^^
>only referenced by instructions in its own module.
^^^^^^
>
>Here's the listing with the changes you suggested [o/p compressed a bit]:
> @@JMP1:
>test.ASM(26): error A2004: Redefinition of symbol
>
> DOSSEG
> .model small
>
> .stack
>
> .code
>
> 0000 proc1 proc
> 0000 B8 ---- R mov ax,@data
> ...
> 0007 E8 0012 R call proc2
> 000A EB 02 90 jmp @@JMP1
>test.ASM(14): error A2026: Reference to multidefined symbol
> 000D 90 nop
> @@JMP1:
>test.ASM(16): error A2005: Symbol is multidefined: @@JMP1
> 000E B4 4C mov ah,4Ch
> 0010 CD 21 int 21h
> 0012 proc1 endp
>
> 0012 proc2 proc
> ...
> 0014 EB F8 jmp @@JMP1
>test.ASM(24): error A2026: Reference to multidefined symbol
> 0016 90 nop
> @@JMP1:
>test.ASM(26): error A2005: Symbol is multidefined: @@JMP1
> 0017 90 nop
> 0018 C3 ret
> 0019 proc2 endp
>
> end proc1
>...
>
> 0 Warning Errors
> 5 Severe Errors
>
I think the problem you have here is that you have mis-interpreted the term
`module'. Normally, `module' refers to a separate source file - i.e. if you
had split your program into two files, one containing proc1 and one with
proc2 and joined them together at linking time. In this case, you can use
the symbol @@JMP1 in each file (i.e. twice with different contexts in the
whole program). e.g.
file proc1.asm
DOSSEG
.model small
proc1 proc
mov ax,@DATA
... ; Whatever the code was here
call proc2
jmp @JMP1
...
JMP1: mov ah, 4CH
int 21H
proc1 endp
external proc2:near ptr ; (HELP! I've suddenly forgotten the correct syntax
; for the external directive!)
---
file proc2.asm
DOSSEG
.model small
public proc2
proc2 proc
jmp @@JMP1
...
@@JMP1: ...
ret
proc2 endp
Now, if you need to refer from one file to the other (as
you would here since proc1 calls proc2, you would have to ensure that
proc2 was made public, so that the linker knows that other modules are
allowed access to it, and that it is noted as external in the file containing
proc1 (so that the assembler knows that it exists). This is what is meant
by referencing labels in other module. Now, if you had made @@JMP1 public too,
and an external reference, the assembler/linker would have tried to reference
that in both modules as the SAME symbol, and failed with a similar error to
the one you were getting - i.e., as the manual says, you can only have two
indentically written labels in different modules if the only references to
them are from within their own modules.
Hope this helps,
Simon
barrym
use @: as a label and do jumps to @f or @b depending on whether it's a
forward or backwards jump. This is documented in the MASM 5.1 upgrade
manual from 5.0.
Tasm lets you do it either way, depending on the assembler mode.
Barry
William Hutto (bhu...@gate.net) wrote:
: In article <47ep5p$h...@life.ai.mit.edu>,
: pi...@gnu.ai.mit.edu (Pixelated!) wrote:
: >In article <47efck$r...@news.gate.net>, William Hutto <bhu...@gate.net> wrote:
: >>>Masm had local labels in 5.0 or 5.1, I forget which. Tasm got them in
: > ^^^^^ ^^^^^^
: >> jmp JMP1
: >
: > jmp @@JMP1
: >
: >> nop
: >>JMP1:
: >
: >@@JMP1:
: >
: >
: >[snip]
: >
: >> jmp JMP1
: >
: > jmp @@JMP1:
: >
: >> nop
: >>JMP1:
: >
: >@@JMP1:
: >
: >1) Make these changes.
: >2) recompile your program.
: >3) Read the manual to find out what a "local label" is.
: >4) Post the revised listing file, and explain to everyone how you
: > feel foolish for posting without a clear understanding of what we
: > meant. :)
: >
: >(sorry if that sounds kind of rude. THis wasn't meant as a flame.)
: Gee, I seem to constantly have to defend myself. Giving you every benefit of
: the doubt I dug out my old 5.1 manual and here's about all it had to say on
: labels:
: page 121
: A near label can appear on a line by itself or on a line with an instruction.
: The same label name can be used in different modules as long as each label is
: only referenced by instructions in its own module.
: Here's the listing with the changes you suggested:
: Microsoft (R) Macro Assembler Version 5.10 11/8/95 16:04:41
: Page 1-1
: @@JMP1:
: test.ASM(26): error A2004: Redefinition of symbol
: Microsoft (R) Macro Assembler Version 5.10 11/8/95 16:04:41
: Page 1-1
: DOSSEG
: .model small
:
: .stack
:
: .code
:
: 0000 proc1 proc
: 0000 B8 ---- R mov ax,@data
: 0003 8E D8 mov ds,ax
: 0005 90 nop
: 0006 90 nop
: 0007 E8 0012 R call proc2
: 000A EB 02 90 jmp @@JMP1
: test.ASM(14): error A2026: Reference to multidefined symbol
: 000D 90 nop
: @@JMP1:
: test.ASM(16): error A2005: Symbol is multidefined: @@JMP1
: 000E B4 4C mov ah,4Ch
: 0010 CD 21 int 21h
: 0012 proc1 endp
:
: 0012 proc2 proc
: 0012 90 nop
: 0013 90 nop
: 0014 EB F8 jmp @@JMP1
: test.ASM(24): error A2026: Reference to multidefined symbol
: 0016 90 nop
: @@JMP1:
: test.ASM(26): error A2005: Symbol is multidefined: @@JMP1
: 0017 90 nop
: 0018 C3 ret
: 0019 proc2 endp
:
: end proc1
: Microsoft (R) Macro Assembler Version 5.10 11/8/95 16:04:41
: Symbols-1
: Segments and Groups:
: N a m e Length Align Combine Class
: DGROUP . . . . . . . . . . . . . GROUP
: _DATA . . . . . . . . . . . . 0000 WORD PUBLIC 'DATA'
: STACK . . . . . . . . . . . . 0400 PARA STACK 'STACK'
: _TEXT . . . . . . . . . . . . . 0019 WORD PUBLIC 'CODE'
: Symbols:
: N a m e Type Value Attr
: PROC1 . . . . . . . . . . . . . N PROC 0000 _TEXT Length = 0012
: PROC2 . . . . . . . . . . . . . N PROC 0012 _TEXT Length = 0007
: @@JMP1 . . . . . . . . . . . . . L NEAR 000E _TEXT
: @CODE . . . . . . . . . . . . . TEXT _TEXT
: @CODESIZE . . . . . . . . . . . TEXT 0
: @CPU . . . . . . . . . . . . . . TEXT 0101h
: @DATASIZE . . . . . . . . . . . TEXT 0
: @FILENAME . . . . . . . . . . . TEXT test
: @VERSION . . . . . . . . . . . . TEXT 510
: 31 Source Lines
: 31 Total Lines
: 20 Symbols
: 47690 + 187073 Bytes symbol space free
: 0 Warning Errors
: 5 Severe Errors
William Hutto
sim...@ic.ac.uk (Dr S.J. Harris) wrote:
>In article <47rmtj$2p...@news.gate.net> bhu...@gate.net (William Hutto)
writes:
>> pi...@gnu.ai.mit.edu (Pixelated!) wrote:
>>>>>Masm had local labels in 5.0 or 5.1, I forget which. Tasm got them in
>>> ^^^^^ ^^^^^^
>
>
>
>>Gee, I seem to constantly have to defend myself. Giving you every benefit of
>>the doubt I dug out my old 5.1 manual and here's about all it had to say on
>>labels:
>>
>>page 121
>>
>>A near label can appear on a line by itself or on a line with an
instruction.
>>The same label name can be used in different modules as long as each label
is
>>only referenced by instructions in its own module.
>>
>>Here's the listing with the changes you suggested [o/p compressed a bit]:
>
>> @@JMP1:
>>test.ASM(26): error A2004: Redefinition of symbol
<snip>
>>
>I think the problem you have here is that you have mis-interpreted the term
>`module'. Normally, `module' refers to a separate source file - i.e. if you
>had split your program into two files, one containing proc1 and one with
>proc2 and joined them together at linking time. In this case, you can use
>the symbol @@JMP1 in each file (i.e. twice with different contexts in the
>whole program). e.g.
>
<snip>
>
>Hope this helps,
>
>Simon
>
>(s.j.h...@ic.ac.uk)
>
Thank you Simon.
Bill