Two messages from DANNYSOFT BBS, captured on 10/4/87. Message #1448 To ALL 09-17-87 From CARLOTTA DECONCILIS Subject PROBLEMS WITH MASM V5.0 --------------------------------------------------------------------------- **** Courtesy of Glenn Dobratz **** The following is a description of the problems which I have encountered in installing the V5.0 release of the MicroSoft Assembler and its support utilities. MASM - The assembler does not detect certain illegal 386 instruction syntaxes and generates bad code for them. Specifically, the 386 now permits the syntax [EBX*n] for indexing, where n is 2, 4, or 8. This automatic scaling is supported only for the extended 32-bit registers. The syntax [BX*n] is not legal, but MASM accepts it and generates a junk instruction. - The assembler no longer accepts the ASCII Form-Feed character as an equivalent to the PAGE directive. If you have been using this to separate the subroutines in your .ASM files, you find that they are no longer on separate listing pages. This is an undocumented difference from V4.0. - PAGE directives are now listed on the first line of the new page instead of the last line of the current page. This change is undocumented. - If you use the .386 directive to access the 80386 instruction set be forewarned that the default for the conditional-jump instructions (Jxx) changes from SHORT to NEAR and all of your conditional jumps which do not have explicit SHORT encodings now become longer and slower. This change is documented. - If you use the .386 directive in some files and do not use it in others, there is no practical way to have neat header files such as DOS.MAC to define your segments. This only affects .ASMs which you are trying to make be compatible with Lattice C; MSC is OK. The problem is that your 386 segments must include either USE16 or USE32 unless you use MicroSoft's default segment names, which Lattice does not. But if you do not use .386 then you are not permitted to put USE16 or USE32 in your segment declarations. This makes it impossible to have one file, such as DOS.MAC, which will work properly regardless of whether or not .386 is present. There is also no way of testing whether or not .386 has been specified, so the .MAC file can't do its segment declarations conditionally. Sigh. LINK - If you mess up your segment definitions and wind up attempting to combine two PUBLIC segments, one of which is USE16 and the other is USE32, then the link will fail with an error L1123 which has no associated text message to tell you what is wrong or where. L1123 is not documented in the manual either. - The new format .EXE files which are generated by LINK are slightly larger than they were for the same program using the previous LINK. MAKE - They have made an undocumented change which breaks old MAKE files which use TOOLS.INI to define inferrence rules. The V4.0 MAKE would not parse the text read from TOOLS.INI for macro replacement until it really needed to use the particular rule. The new MAKE performs macro replacement on the TOOLS.INI text when it reads the file in, which is done before your MAKE file is read. This means that your program cannot define/redefine macros which are used in TOOLS.INI since the replacement is done before your macros are scanned. This makes it impossible for a MAKE file to 'communicate' options, etc., via macros, to the inferrence rules in TOOLS.INI. - The problem with the old MAKE that it does not conform to the documentation on how TOOLS.INI is scanned has not been corrected. Inferrence rules which are defined in TOOLS.INI are still mutually exclusive with the inferrence rules which are defined in your MAKE file. The documentation says that rules in your MAKE file have priority over the rules defined in TOOLS.INI. If you encounter an problems which I have not enumerated above, I would very much like to here about them. You may contact me by leaving a message for me on the Lattice BBS or at the phone number below between 12:00 and 18:00 CT. Glenn Dobratz (312) 882-7305 LBBS(312) 916-1200(9600/2400/1200/300/8/N/1) * * * * * * * * * * * Message #1709 To CARLOTTA DECONCILIS 09-28-87 (Rcvd) From FRANK HABER Subject (R)PROBLEMS WITH MASM V5. --------------------------------------------------------------------------- How 'bout 'dis? Fm: SysOp Chris Dunford 76703,2002 To: Don 73047,1113 The four bugs that I know about (courtesy of Bob Smith): 1. A problem with ASSUME. Sometimes MASM fails to detect that none of the segment registers are set to address an data object and invalid code is generated (a DS override where DS doesn't address the object). No warning or error messages. 2. Sometime it computes the length of an instruction differently on the two passes and does not warn. Then it outputs two object records for the instruction. LINK then adds nulls, rsulting in the execution of the instruction ADD [BX][SI],AL. No error messages, and the LST file appears to be correct. 3. Certain constructs cause no public records to be emitted for objects declared to be PUBLIC. (Bob says he reported this bug to MS in 1985, with sample code.) 4. Certain kinds of nested structures that should work, don't. 3 and 4 I can live with, but 1 and 2 are very nasty.