weiss@theory.lcs.mit.edu (Paul G. Weiss) (11/20/90)
Here are two things that I don't like about the Microsoft Assembler. If someone from M-Soft is listening can you tell me if the latest version fixes these problems. First of all, the version that I am using is 5.10A. Problem #1: High level language support --------------------------------------- When using the .MODEL directive which provides high level language support, e.g. .MODEL SMALL,PASCAL all procedures are declared public. As far as I know there is no way to inform the assembler that you do not want certain procedures to be made public. This is a real problem if you are going to be distributing libraries, as it causes many symbols to be included in the library index that otherwise would be hidden. Problem #2: .CODE directive --------------------------------------- When you specify .MODEL MEDIUM or .MODEL LARGE you can then give the .CODE directive a name, e.g. .CODE FOO_TEXT This will translate into FOO_TEXT SEGMENT WORD PUBLIC 'CODE' Unfortunately, if your filename is BAR.ASM, then your object file will also contain a definition of the following segment: BAR_TEXT SEGMENT WORD PUBLIC 'CODE' Even if you do not place any data in this segment. Again, for those of us who distribute libraries this results in lots of null segments being placed in the library, making our libraries larger and confusing people who read link maps after linking with the library. Thanks for listening. -Paul Weiss
c164-bd@cinna.uucp (John D. Mitchell) (11/20/90)
In article <WEISS.90Nov19164930@toucan.lcs.mit.edu> weiss@theory.lcs.mit.edu (Paul G. Weiss) writes: >Here are two things that I don't like about the Microsoft Assembler. If >someone from M-Soft is listening can you tell me if the latest version >fixes these problems. > >First of all, the version that I am using is 5.10A. I'd suggest that you switch to another assembler (such as OPTASM or Borland's TASM). Masm (from what I have heard second hand) isn't even written in 80x86 assembly language. It's written in 'C'. Both OPTASM (by SLR Systems) and TASM (v2.0) are at least two or three times as fast as MASM, produce better code, and have more useful features. Good luck, John D. Mitchell johnm@cory.Berkeley.EDU
ted@polyof.poly.edu (Theodore S. Kapela, Staff) (11/20/90)
In article <9078@pasteur.Berkeley.EDU> c164-bd@cinna.UUCP (John D. Mitchell) writes: [text deleted] >Both OPTASM (by SLR Systems) and TASM (v2.0) are at least two or >three times as fast as MASM, produce better code, and have more ^^^^^^^^^^^^^^^^^^^ I don't know about anyone else, but I don't want the assembler I am using to 'produce' any code that I haven't written. I expect it to generate the correct machine code instructions for the assembler instructions I wrote. And, the last I checked, there is a unique pattern of bits for each mnemonic (but not necesarily the other way around); ie: each instruction can only be coded one way, although some instructions share the same bit pattern. JNZ and JNE are just one pair I can think of. If you mean such things as 'nop crunching', you are correct. MASM has a nice little habit of putting 'nop's to fill instructions it expects to be a certain size (eg: a jmp instruction (relative) is expected to be a total of three bytes. If the jmp happens to be a short jmp (offset fits in a byte), it generates the appropriate code, but adds a nop to fill the instruction to three bytes). I have used both MASM and TASM. I am getting to like TASM better, especially because it is quite a bit faster. > >Good luck, > John D. Mitchell > johnm@cory.Berkeley.EDU -- .............................................................................. Theodore S. Kapela (516) 755-4299 [Voice, Days] ted@polyof.poly.edu (516) 473-7746 [FAX] "Another brilliant mind corrupted by education"
c164-bd@cinna.uucp (John D. Mitchell) (11/21/90)
In article <1990Nov20.141330.13358@polyof.poly.edu> ted@polyof.poly.edu (Theodore S. Kapela, Staff) writes: >In article <9078@pasteur.Berkeley.EDU> c164-bd@cinna.UUCP (John D. Mitchell) writes: > > [text deleted] > >>Both OPTASM (by SLR Systems) and TASM (v2.0) are at least two or >>three times as fast as MASM, produce better code, and have more > ^^^^^^^^^^^^^^^^^^^ >I don't know about anyone else, but I don't want the assembler I am using >to 'produce' any code that I haven't written. I expect it to generate >the correct machine code instructions for the assembler instructions >I wrote. And, the last I checked, there is a unique pattern of bits for >each mnemonic (but not necesarily the other way around); ie: each >instruction can only be coded one way, although some instructions share >the same bit pattern. JNZ and JNE are just one pair I can think of. > Not quite. The 80x86 instruction set has some bizarre quirks (mostly due to its bastard heritage. There are some special forms of certain instructions that are smaller/faster than the regular version. For example (off the top of my head) there is a version of mov that is both one byte smaller and executes in less time because it assumes a ax destination. Yes, I was originally thinking of jump optimization. OPTASM has a more powerful macro language than either MASM or TASM. TASM and OPTASM are faster and have better diagnostics/error messages. TASM v2.0 has new call syntax that allows for easier multi-high-level- language interfacing. Procedure call, entry, and exit are much more likely to match. (I.e. procedure argument handling is almost as easy as C or Pascal). Thanks, John D. Mitchell johnm@cory.Berkeley.EDU
david@csource.oz.au (david nugent) (11/21/90)
In <WEISS.90Nov19164930@toucan.lcs.mit.edu> weiss@theory.lcs.mit.edu (Paul G. Weiss) writes: > Problem #1: High level language support > --------------------------------------- > When using the .MODEL directive which provides high level language > support, e.g. > .MODEL SMALL,PASCAL > all procedures are declared public. Yes, a real drag, isn't it? TASM in "ideal" mode doesn't reproduce this bug. :-) > As far as I know there is no > way to inform the assembler that you do not want certain procedures > to be made public. This is a real problem if you are going to be > distributing libraries, as it causes many symbols to be included > in the library index that otherwise would be hidden. I use a macro called pProc and pEndP which do much the same as PROC and ENDP, except that they aren't so smart about setup and breakdown code for the stack. But they produce a nice private routine... Some interesting reference - if you're interested in producing such a macro - is the cmacros.inc that (used to be?) is supplied with MASM. Actually, I found that particular file more enlightening as regards to using macros than the entire manual! I've since done a great deal of work on it though, it seems that as at MASM 5.1, it hadn't been updated for many of the new macro constructs that version introduced, most of which resulted in that file being reduced to around 1/3 it's original size. > Problem #2: .CODE directive > --------------------------------------- > When you specify > .MODEL MEDIUM > or > .MODEL LARGE > you can then give the .CODE directive a name, e.g. > .CODE FOO_TEXT > This will translate into > FOO_TEXT SEGMENT WORD PUBLIC 'CODE' > Unfortunately, if your filename is BAR.ASM, then your > object file will also contain a definition of the > following segment: > BAR_TEXT SEGMENT WORD PUBLIC 'CODE' > Even if you do not place any data in this segment. Makes for lots of empty segments in the .MAP file. BTW, TASM also does this. Again, a real pain, but you can live with it because it's basically harmless. I use it a lot in mixed model programming to force certain code to reside in the same segment, for fast and efficient near calls. - david -- Fidonet: 3:632/348 SIGnet: 28:4100/1 Imex: 90:833/387 Data: +61-3-885-7864 Voice: +61-3-826-6711 Internet/ACSnet: david@csource.oz.au Uucp: ..!uunet!munnari!csource!david
david@csource.oz.au (david nugent) (11/22/90)
> TASM v2.0 has new call syntax that allows for easier multi-high-level- > language interfacing. Procedure call, entry, and exit are much > more likely to match. (I.e. procedure argument handling is almost > as easy as C or Pascal). Not at all new to TASM. In fact, Borland's imitation of MASM's HLL is a little incomplete in places. -- Fidonet: 3:632/348 SIGnet: 28:4100/1 Imex: 90:833/387 Data: +61-3-885-7864 Voice: +61-3-826-6711 Internet/ACSnet: david@csource.oz.au Uucp: ..!uunet!munnari!csource!david
zhou@brazil.psych.purdue.edu (Albert Zhou) (11/23/90)
>Both OPTASM (by SLR Systems) and TASM (v2.0) are at least two or >three times as fast as MASM, produce better code, and have more ^^^^^^^^^^^^^^^^^^^ Isn't one-to-one translation from Assembly to machine codes. How come "better" code?
bking@nro.cs.athabascau.ca (Barry King) (11/26/90)
zhou@brazil.psych.purdue.edu (Albert Zhou) writes: > >Both OPTASM (by SLR Systems) and TASM (v2.0) are at least two or > >three times as fast as MASM, produce better code, and have more > ^^^^^^^^^^^^^^^^^^^ > Isn't one-to-one translation from Assembly to machine codes. How come "better > code? This is TERRIBLY petty but...now who's not so technical??? Assemblers do _not_ always do one to one translations. References to objects which are not well defined in the first pass, f'rinstance, may result in sequences of NOPs being produced. MASM assumes far addresses the first time through and goes back and 'fixes' any of those references that are actually near and inserts NOPs. Also segment fixups affect the generated code. Pseudo opcodes may be implemented differently by different assemblers, too. Anyway, it's dangerous to cast stones, isn't it...not everyone on this net has the same level of technical expertise and part of the point of this communication medium is to share information... nuff said
steveha@microsoft.UUCP (Steve Hastings) (11/29/90)
_PC Week_ magazine, 19 Nov 90 issue, page 4, in an article called "Microsoft to Beef Up Macro Assembler Compiler," says that MASM 6.0 is in beta test. They said it is integrated with Programmer's WorkBench 1.1, is faster, is a one-pass assembler (no more NOP holes), and has support for high-level-ish constructs like "if-then-else" and loops. I have never laid eyes on this product, so I cannot verify any of this. -- Steve "I don't speak for Microsoft" Hastings ===^=== ::::: uunet!microsoft!steveha steveha@microsoft.uucp ` \\==|
c164-bd@katerina.uucp (John D. Mitchell) (12/01/90)
In article <59413@microsoft.UUCP> steveha@microsoft.UUCP (Steve Hastings) writes: >_PC Week_ magazine, 19 Nov 90 issue, page 4, in an article called >"Microsoft to Beef Up Macro Assembler Compiler," says that MASM 6.0 is in >beta test. They said it is integrated with Programmer's WorkBench 1.1, is >faster, is a one-pass assembler (no more NOP holes), and has support for >high-level-ish constructs like "if-then-else" and loops. > >I have never laid eyes on this product, so I cannot verify any of this. What do you (they) mean 'one-pass assembler (no more NOP holes)'? In a true single pass assembler you can't know how far ahead the target of a jump/call/branch is, so how can you produce the correct code? They might be doing some kind of back-patching but that would seem to mean that it's no longer a one-pass assembler. Both SLR's OPTASM and Borland's TASM are very fast and they use a multi-pass system. Also, I lean towards the school of thought that says "if you need help to do simple things like looping and if-then-else's then what the hell are you doing using assembly-language?!" I would tend to trust such sneak preview articles with suspicion (which you did). I have heard a few discussions about questionable marketing practices (ethically speaking, nothing per se about M-soft) where information is purposefully 'leaked' about performance/features/etc. that the actual product doesn't/won't have. I'll believe it when I rake it over the coals a few times :-). Oh yeah, any word about whether they are finally going to write the assembler in assembly language (instead of C)? ----- John D. Mitchell johnm@cory.Berkeley.EDU
otto@tukki.jyu.fi (Otto J. Makela) (12/02/90)
In article <9385@pasteur.Berkeley.EDU> c164-bd@katerina.uucp (John D. Mitchell) writes:
[re new version of MASM]
Oh yeah, any word about whether they are finally going to write the
assembler in assembly language (instead of C)?
Should it make any difference ? The fact that it's slow doesn't have very
much to do with what language it's done in. You can make assembler slower
than molasses in frozen-over hell.
--
/* * * Otto J. Makela <otto@jyu.fi> * * * * * * * * * * * * * * * * * * */
/* Phone: +358 41 613 847, BBS: +358 41 211 562 (CCITT, Bell 24/12/300) */
/* Mail: Kauppakatu 1 B 18, SF-40100 Jyvaskyla, Finland, EUROPE */
/* * * Computers Rule 01001111 01001011 * * * * * * * * * * * * * * * * */Ralf.Brown@B.GP.CS.CMU.EDU (12/02/90)
In article <9385@pasteur.Berkeley.EDU>, c164-bd@katerina.uucp (John D. Mitchell) wrote: }mean that it's no longer a one-pass assembler. Both SLR's OPTASM and }Borland's TASM are very fast and they use a multi-pass system. Er.... TASM 1.0x was one-pass; TASM 2.0 is normally one-pass, but will make multiple passes if you use certain features or give a command-line switch. -- UUCP: {ucbvax,harvard}!cs.cmu.edu!ralf -=- 412-268-3053 (school) -=- FAX: ask ARPA: ralf@cs.cmu.edu BIT: ralf%cs.cmu.edu@CMUCCVMA FIDO: 1:129/3.1 Disclaimer? | I was gratified to be able to answer promptly, and I did. What's that? | I said I didn't know. --Mark Twain
c164-bd@cordelia.uucp (John D. Mitchell) (12/03/90)
In article <OTTO.90Dec2080958@tukki.jyu.fi> otto@tukki.jyu.fi (Otto J. Makela) writes: >In article <9385@pasteur.Berkeley.EDU> c164-bd@katerina.uucp (John D. Mitchell) writes: > Oh yeah, any word about whether they are finally going to write the > assembler in assembly language (instead of C)? >Should it make any difference ? The fact that it's slow doesn't have very >much to do with what language it's done in. You can make assembler slower >than molasses in frozen-over hell. Of course, my comment comes more from a desire to question M-soft's thinking than anything else. Everything I have ever seen by them is large and slow. Yes, there's plenty I haven't seen. Speed IS an issue to many people. Look at how well Borland's done. You're absolutely correct (if I am inferring correctly) that proper design (algorithms, data structures, etc.) make a much larger impact then language choice (where the languages are roughly comparable). If they can produce an assembler that's as fast as the current version of TASM and is as easy to use then I'll check it out. No more quirky bugs, inconsistent macros, etc. (Good luck! :-) Thanks, John D. Mitchell johnm@cory.Berkeley.EDU
rcollins@altos86.Altos.COM (Robert Collins) (12/05/90)
In article <9393@pasteur.Berkeley.EDU> c164-bd@cordelia.UUCP (John D. Mitchell) writes: >If they can produce an assembler that's as fast as the current version >of TASM and is as easy to use then I'll check it out. No more >quirky bugs, inconsistent macros, etc. (Good luck! :-) > Disclaimer: I'm one of the worst M-Soft bashers around...but... I can work around the bugs in MASM 5.1. The bugs in TASM 2.0 are show-stoppers to me. I can't use it. Just don't try and use TASM (or TLINK) with USE32 code, 32-bit equates, or 32-bit variables. TASM simply, and without warning clears the upper 16-bits. For example: PromBase equ 0FFFC0000h FOO DD PromBase + FOO2 ; TLINK truncates as 00000206h ; in the LINK process. FOO1 DW PromBase MOD 10000h ; Tasm BARFS with an error FOO2 DW PromBase / 10000h ; Tasm BARFS with an error If you're doing any type of 32-bit code, or protected mode programming where you would like all your descriptor tables to be built dynamically, then TASM won't be able to do it. These are total show-stoppers. I've called Borland, and got a guy on tech-support that said something like: "If our engineers determine this to be an error, they MIGHT fix it...depending on how serious they think it is." Speed is nothing without proper functionality. Hey, I've got the fastest computer in the world! It does an infinite loop in just 3.2 seconds! -- "Worship the Lord your God, and serve him only." Mat. 4:10 Robert Collins UUCP: ...!sun!altos86!rcollins HOME: (408) 225-8002 WORK: (408) 432-6200 x4356