Comparison of assemblers

Index > Main > Comparison of assemblers

Goto page Previous 1, 2, 3, 4, 5 Next

Author

Thread

Japheth

Joined: 26 Oct 2004
Posts: 151

Japheth 21 Oct 2006, 15:35

Hi,

vid wrote:

okay, let's start about MASM optimizing... i bet MASM is not optimizing size of jumps, or at least fails to do it often (FASM fails seldom). This very basic example produced short jumps in FASM, but not in MASM:
Code:
@@: jmp @f
db 124 dup(?)
jmp @b
@@:    
(still, someone try it, i am not sure if mazegen compiled it right way with some optimizng command line switches, if they are there)

I bothered to assemble your sample with MASM v6.15 and both jumps are short. Could you please supply info what version you used?

21 Oct 2006, 15:35

vid
Verbosity in development

Joined: 05 Sep 2003
Posts: 7103
Location: Slovakia

vid 21 Oct 2006, 15:43

Japheth: i was trying to assemble it with MazeGen on his machine, during our way to (or from?) Krakow. No idea which version it was. Maybe we just messed something. Good info for MASM users than, thanks!

btw, did you have to turn on some optimization flags for this?

21 Oct 2006, 15:43

Japheth

Joined: 26 Oct 2004
Posts: 151

Japheth 22 Oct 2006, 18:51

Hi vid,

> btw, did you have to turn on some optimization flags for this?

No. There are no such flags in MASM.

22 Oct 2006, 18:51

MazeGen

Joined: 06 Oct 2003
Posts: 977
Location: Czechoslovakia

MazeGen 23 Oct 2006, 17:23

Japheth, I don't think we can use v6.15 seriously in this comparison since it is outdated (even though widely used along with 6.14).

As for MASM v8.00.50727.42, these codes generate the following results. I thing it is clear where is the difference:

Code:

                                .686
                                .MODEL FLAT, STDCALL

 00000000                       .CODE
 00000000                       Start:

 00000000  E9 00000081          @@: jmp @f
 00000005  0000007C [           db 124 dup(?)
            00
           ]
 00000081  E9 FFFFFF7A          jmp @b
 00000086                       @@:

                                END Start

Code:

                                .686
                                .MODEL FLAT, STDCALL

 00000000                       .CODE
 00000000                       Start:

 00000000  EB 7E                @@: jmp short @f
 00000002  0000007C [           db 124 dup(?)
            00
           ]
 0000007E  EB 80                jmp short @b
 00000080                       @@:

                                END Start

23 Oct 2006, 17:23

Japheth

Joined: 26 Oct 2004
Posts: 151

Japheth 23 Oct 2006, 17:59

Hi MazeGen

> As for MASM v8.00.50727.42,

I see now, the problem occurs if code segment is 32-bit, it is independant from the MASM version.

23 Oct 2006, 17:59

vid
Verbosity in development

Joined: 05 Sep 2003
Posts: 7103
Location: Slovakia

vid 15 Nov 2006, 14:13

allright... new version in first post. I won't add new criterias, until these are finished. So here is what i need.

Also, i changed "output formats" only to formats that can be directly outputted by assembler. I don't include formats they are linked to anymore.

- find out exact EULAs of MASM, from various sources.
- does MASM support input in other format tahn pure text? (eg UTF-8, unicode...)
- what are MASM's debug formats? (including old DOS ones)
- when was NASM project started?
- does NASM support input in other format tahn pure text? (eg UTF-8,
- has YASM support for shared ELF format?
- does YASM have listing?
- info about RosAsm... betov?
- info about GoAsm... jeremy?

PS: if you find something you consider not objective, please report.

15 Nov 2006, 14:13

rugxulo

Joined: 09 Aug 2005
Posts: 2341
Location: Usono (aka, USA)

rugxulo 16 Nov 2006, 03:20

I think there are two MASM versions being supposedly legally distributed (separate from VC++): MASM32 (hutch) and GeneSys (Paul and Erol)
- IMO, they are NOT worth fooling with, especially because of the insane license(s):
  
  Quote:
  
  What you CANNOT do with the MASM32 Project.
  4. You cannot use the MASM32 Project to write software for Non-Microsoft Operating Systems.
  
  Ridiculous! Can anybody tell me how sharing code between OSes hurts someone? Anyone???
NASM 0.91 was the first version (files dated circa Nov. 1996)
YASM has listing, but IIRC, it's taken from NASM
MASM outputs CodeView debug info
... also,
OpenWatcom (compiler, at least) outputs DWARF debug info by default (other formats supported: CodeView, Watcom) ... but debugging DOS programs on XP won't work (debugger is buggy, ha!, needs pure DOS for debugging DOS programs)
LZASM (Lazy) outputs Borland debug info (though I've never tried using it w/ TD or any other debugger)

Last edited by rugxulo on 21 Nov 2006, 14:59; edited 1 time in total

16 Nov 2006, 03:20

rugxulo

Joined: 09 Aug 2005
Posts: 2341
Location: Usono (aka, USA)

rugxulo 16 Nov 2006, 03:55

BTW, vid, here's some minor corrections to CMPASM.TXT:

NASM is NOT dead (CVS last updated 8 months ago, at least)
NASM does support limiting to specific processor ("cpu 8086") ... and so does YASM (just tested r1633 to be sure)
NASM only supports RDOFF 2 nowadays
YASM is indeed active (see timeline or latest snapshots)
NASM supports `Pentium', `P6', `MMX', `3DNow!', `SSE' and `SSE2' opcodes

16 Nov 2006, 03:55

vid
Verbosity in development

Joined: 05 Sep 2003
Posts: 7103
Location: Slovakia

vid 16 Nov 2006, 06:03

thanks.

btw, 8 months is not far from dead for me. also last normal release is 4 years old !

16 Nov 2006, 06:03

Japheth

Joined: 26 Oct 2004
Posts: 151

Japheth 16 Nov 2006, 11:53

> # OpenWatcom (compiler, at least) outputs DWARF debug info by default
> (other formats supported: CodeView, Watcom) ... but debugging DOS
> programs on XP won't work (debugger is buggy, ha!, needs pure DOS for
> debugging DOS programs)

No. Indeed it works ok. But you must use "remote" debugging, which in this context just means you have to use 2 "DOS boxes". Example:

1. DOS box: C:\>vdmserv
2. DOS box: C:\>wd /tr=vdm <name of debuggee>

However, the OW GUI debugger (WDW) should be avoided to debug DOS apps.

16 Nov 2006, 11:53

rugxulo

Joined: 09 Aug 2005
Posts: 2341
Location: Usono (aka, USA)

rugxulo 16 Nov 2006, 22:50

Japheth, you are correct, I just didn't understand all that mumbo-jumbo about remote debugging (mistakenly though I needed another cpu).

Quote:

cmd.exe
watcom.bat & echo (sets up %PATH%, %WATCOM%, etc.)
wasm.exe -d3 myfile.asm
wlink debug watcom all format dos com file myfile.obj file myfile.com
vdmserv

cmd.exe
watcom.bat
wd /tr=vdm myfile.com

The above works using the old non-default Watcom debug format but using default DWARF format crashes the debugger and using Codeview doesn't show symbolic info (e.g., labels). Maybe I did it wrong, though. Razz

Tested on Win XP Home SP2.

16 Nov 2006, 22:50

rugxulo

Joined: 09 Aug 2005
Posts: 2341
Location: Usono (aka, USA)

rugxulo 16 Nov 2006, 23:33

EDIT: This info is old, so just visit OpenWatcom's official site instead.

BTW, just to combine all the info from various other posts of mine (sorry if it's messy, I tried, really I did ...):

The latest stable version of OpenWatcom is 1.6 ( changes ). This means that __WATCOMC__ = 1260 (OpenWatcom 1.0 was 1200, 1.1 was 1210, etc.).
In 1.4, OpenWatcom added a real-mode assembler (e.g., for 8086) that uses less memory (WASMR) than the 386 pmode version, plus beta assemblers for other architectures like PowerPC and Alpha AXP (WASPPC 0.3, WASAXP 0.8 ). I think the x86-targetting assembler only supports a subset of MASM syntax. AFAIK, all these assemblers (except WASMR) have versions that run on both DOS and OS/2, but WASM also has an Win32 (NT only?) version
- P.S. real/pure DOS users: get EXT_DOS4G.ZIP (or whatever extender you prefer and restub the .EXEs), you need it!
Quote:
List of changes in OpenWatcom C/C++ 1.6
- The assembler (wasm) now supports external absolute symbols. The SIZE, SIZEOF, LENGTH, and LENGTHOF operators have been corrected for structures.
- Classification of privileged instructions in the assembler has been updated to match MASM.
- The assembler now evaluates expressions in return instructions correctly. Previously, code such as 'ret 28+4' would be sometimes erroneously assembled as 'ret 28' instead of 'ret 32'.
List of changes in OpenWatcom C/C++ 1.5
- The linker and other tools have been fixed to correctly classify code segments. Previously, code segments could be misclassified as data, which led to incorrect disassembly and generation of debugging information.
List of changes in OpenWatcom C/C++ 1.4
- The disassembler (wdis) now handles big endian object files on little endian host platforms, and vice versa.
- Support for MIPS R4000 and SPARC V8 instruction sets has been added to the disassembler.
- New -zz and -zzo option have been added to the assembler (wasm) for backwards compatibility. See Tools User's Guide for details.
- Default behaviour of inline assembler has changed. The CPU optimization level (-4, -5, -6) now implies the available instruction set: -5 implies MMX and 3DNow!, -6 also implies SSE/SSE2/SSE3. Also note that any CPU setting override now reverts to default at the end of each inline assembly block.
- 16-bit DOS version of the assembler (wasmr) has been added. This version runs on 8086 and above and requires less memory than the protected mode version.
- Support for Microsoft/IBM .sym files generated by the MAPSYM utility has been added to the debugger and profiler. This is helpful especially with symbol files provided by IBM for OS/2 system DLLs; disassembly now shows for instance "call DOS32EXIT" instead of "call 01C74634".
- The CauseWay DOS extender now supports SSE instructions on plain DOS.
List of changes in OpenWatcom C/C++ 1.3
- Support for SSE, SSE2, SSE3 and 3DNow! instruction sets has been added. Affected tools are the assembler (wasm), as well as all x86 compilers, disassembler and debugger. The debugger now also supports MMX registers formatted as floats (for 3DNow!) as well as a new XMM register window for SSE.
- Inline assembler directives .MMX, .K3D, .XMM, .XMM2 and .XMM3 are now supported in the _asm as well as #pragma aux style inline assembler interface. Note: .MMX directive is now required (in addition to .586) to use MMX instructions.
- C and C++ x86 inline assembler has been fixed to properly process hexadecimal constants postfixed with 'h'.
- The disassembler (wdis) now correctly processes x86 'push 8-bit immediate' instructions.
- The disassembler now correctly processes absolute memory references. All memory references without fixup are now disassembled as ds:[...] or sreg:[...].
List of changes in OpenWatcom C/C++ 1.2
- The wasm assembler has been enhanced to generate file dependency information usable by wmake.
- Numerous minor fixes have been made to wasm.
- Compatibility with MASM 6 has been improved with wasm.
- Support for sysenter and sysexit instructions has been added to wasm and wdis.
- Disassembly of xchg and bound instructions has been fixed in wdis (corrected order of operands).
List of changes in OpenWatcom C/C++ 1.1
- The assembler did not generate implicit segment override prefixes when accessing data in code segment.
there's a quick summary announcement from the FreeDOS team about what you may need/may not need (i.e., selective install)
OW 1.6 .ZIPs -- files @ ibiblio.org
OW 1.6 DESCRIPT.ION -- (describe what files are needed for what host/target)
OW 1.6 README.TXT -- (general environment setup info)
OW 1.6 LICENSE.TXT -- (license)

Last edited by rugxulo on 05 Dec 2007, 14:24; edited 7 times in total

16 Nov 2006, 23:33

rugxulo

Joined: 09 Aug 2005
Posts: 2341
Location: Usono (aka, USA)

rugxulo 17 Nov 2006, 00:19

Also, the following assemblers support listings (.LST): MASM, TASM, A86/A386, Arrowsoft, Wolfware (WASM.COM), NASM, YASM, Lazy (LZASM), NewBasic (NBASM/NBASM32), and FASM (via optional patch).

vid, I recommend that you also focus on Lazy (LZASM), OpenWatcom (WASM.EXE), and Octasm since they are still supported/updated, run on multiple OSes (DOS, Win32, other), and are aware of MMX, SSE, etc. instructions. (I understand you are limited in time, but they are worthy of further scrutiny).

17 Nov 2006, 00:19

Maverick

Joined: 07 Aug 2006
Posts: 251
Location: Citizen of the Universe

Maverick 17 Nov 2006, 06:34

I used and appreciated++ Watcom in the DOS times, then when I migrated to Windows, I slowly but then definitely abandoned it for VisualC (although I wasn't exactly happy about it at first).

Now that Watcom's development has been restarted and went considerably ahead, what would be the advantages of OpenWatcom vs VC2005 Express?

Expecially in terms of code generation, optimizations, C++ ISO compliance, etc..

Would it make any sense to migrate back to it?

17 Nov 2006, 06:34

vid
Verbosity in development

Joined: 05 Sep 2003
Posts: 7103
Location: Slovakia

vid 17 Nov 2006, 16:02

rugxulo: you are right i should add Lazy. Not sure yet about OpenWatcom and Octasm. But i am *very* limited on time now, so i may add them later. I just can't take too much on one hit. Maybe if authors would cooperate and fill in information for me (you know the criteria), i will add it.

17 Nov 2006, 16:02

rugxulo

Joined: 09 Aug 2005
Posts: 2341
Location: Usono (aka, USA)

rugxulo 17 Nov 2006, 19:05

Maverick, since OpenWatcom is open source now, it should only get better, especially if people use it and report bugs/patches/etc. As far as whether it's worthwhile, I'd say yes, but then again, I don't use it exclusively. (You're allowed to use more than one compiler, ya know.) Very Happy

P.S. Read the changes from recent versions, if you're curious (provides some nifty info).

17 Nov 2006, 19:05

rugxulo

Joined: 09 Aug 2005
Posts: 2341
Location: Usono (aka, USA)

rugxulo 21 Nov 2006, 14:21

Okay, I'm not really advocating bothering with it (Japheth, you recommend POASM instead, no?), but it does look like MASM 8.0 is available for non-commercial use (if you have VC++ 2005 Express, otherwise "it won't install").

21 Nov 2006, 14:21

vid
Verbosity in development

Joined: 05 Sep 2003
Posts: 7103
Location: Slovakia

vid 21 Nov 2006, 15:21

rugxulo: i already have it in document, but in version that isn't uploaded yet.

21 Nov 2006, 15:21

Japheth

Joined: 26 Oct 2004
Posts: 151

Japheth 21 Nov 2006, 16:53

> Japheth, you recommend POASM instead, no?

Since development of PoASM seems to have stopped and source is closed, no!

> since OpenWatcom is open source now, it should only get better

This most likely is true for the 32-bit C/C++ compiler, which are good tools, but the other OW stuff is well below that quality level, including WASM.

21 Nov 2006, 16:53

f0dder

Joined: 19 Feb 2004
Posts: 3174
Location: Denmark

f0dder 22 Nov 2006, 00:44

Apart from the ml.exe license, don't forget this further restriction imposed on you by the MASM32 license, if you use any of that mess:

grumpyoldfart wrote:

Exclusion of open source projects and software.
The MASM32 project cannot be used to create open source software or any other project under any form of licence that requires the user of the MASM32 project to surrender the rights they are afforded under the MASM32 licence. In particular the MASM32 licence completely excludes projects licenced under the GNU organisation's published GPL licence and/or variants.

22 Nov 2006, 00:44

Goto page Previous 1, 2, 3, 4, 5 Next

< Last Thread | Next Thread >

Forum Rules:

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum