Slashdot Mirror
x86 Assembler JWASM Hits Stable Release
Odoital writes "January 2010 is an exciting month for x86 assembly language developers. Software developer Andreas Grech, better known to the x86 assembly language community and the rest of the world by his handle "japheth," has released another version of JWASM — a steadily growing fork of the Open Watcom (WASM) assembler. The main benefit of JWASM, arguably, is the nearly full support of Microsoft's Macro Assembler (MASM) syntax. As those in the assembly language community may already know, Microsoft's desire to continually support the development of MASM has been dwindling over the years — if only measurable by a decreasing lack of interest, updates and bug fixes — and thus the future of MASM remains uncertain. While Intel-style syntax x86 assemblers such as NASM have been around for a while, JWASM opens up a new possibility to those familiar with MASM-style syntax to develop in the domains (i.e. other than Windows) in which assemblers such as NASM currently thrive. JWASM is a welcomed tool that supplements the entire x86 assembly language community and will hopefully, in time, generate new low-level interests and solutions."
And how does its syntax differs from NASM and AT&T ?
Intel syntax doesn't feel like it was designed by a sadist.
More seriously, this site link covers some differences. Among the things I like much more about Intel syntax: there's no need to add a ton of visual noise with what-should-be-extraneous $ and % symbols, and things like memory indirection is much easier to learn. Compare "[ebx+ecx*4h-20h]" to "-0x20(%ebx,%ecx,0x4)"; the former almost tells you what it does even if you're not at all familiar with the syntax, the latter definitely doesn't.
The main benefit that AT&T syntax has is that they "hungarian notation" their instructions: movb works on 1 byte, movw on 2 bytes, movl on 4. Most of the time this is extra visual noise (I don't need the 'l' to tell me that 'mov eax, ebx' works on 4 bytes), but it does make memory dereferences more concise. With Intel syntax you'll get a lot of 'dword ptr' stuff lying around to tell how much should be brought in from memory.
Not quite. There are always situations when writing an operating system where you need assembly. For example, impelmenting the actual 'guts' of a context switch requires fine tuned control over what is in each register.
(C programs tend to assume the stack is available. But in the middle of a context switch, it might not. Assembly gives that level of control).
The big difference is the syntax. Microsoft's assembler uses Intel syntax, while the GNU assembler uses AT&T syntax. The order of operands is different, the syntax for the different addressing modes is different, and instructions have operand size suffixes in AT&T syntax. Beyond that, there are differences in the types and flexibility of the macro system. GNU assembler, for example, uses the C preprocessor for macros, which sucks for C and is even worse for anything else. Other assemblers have complex macro languages.
I am TheRaven on Soylent News
Be warned -- JWASM's Wikipedia article was nominated for deletion, as it was thought that notability was not sufficiently asserted. The flame war there might spill over here as well. :-(
Bits of the C standard library too. You can't implement setjmp() or longjmp() in C, while they're pretty trivial in assembly. Various other functions (e.g. most of math.h) will probably be faster with some inline assembly too, although these days compilers tend to provide built in versions of these functions that you can call and have them replaced with a single instruction.
I am TheRaven on Soylent News