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."
To know how abandoned MASM really is... try and make an assembler project in 64 bit under Visual Studio 2008. It's not even supported out of the box - like, they never actually tested the configuration.
But, for all that, I prefer YASM as the assembler. Still, congrats to the OpenWatcom port.. NICE WORK. It's always good to have more hands in an area that so many people see as dead.
This is my sig.
I loved saying in an interview "I see you have x86 assembler on your resume". The color drains from the kid's face, I give 'em a snippet:
cwd
xor ax,dx
sub ax,dx
It's nothing rocket, just some fun with 2s-complement.
-- Rabid
January 2010 is an exciting month for x86 assembly language developers.
I'm sure the two of them will be pleased.
Japheth has a number of rather interesting projects that extend the functionality of DOS.
Awesome, I'm always on the lookout for cool stuff like this to keep my DOS workstation cutting edge.
sic transit gloria mundi
I still weep slightly when I think of Watcom and their products. They were, by far, among the best out there in the 1980s and early 1990s. I mean, they made Borland's offerings look like garbage, and Borland was pretty damn good at that time, too.
Their assembler and C and C++ compilers were fucking amazing. Nobody generated faster code than them. I remember once moving some code from Microsoft's C++ compiler to Borland C++, and getting a 5 times speedup. Then we moved it from Borland C++ to Watcom C++, and got an additional 8 times speed improvement! We were totally blown away. Their code generator was just that much better than that of much larger competitors.
Watcom SQL was another gem. So much faster than the competition, but also so much easier to use and develop for. It's good to know that Sybase has kept this product alive and well.
To see such a small shop create some high-quality products is truly a testament to the fantastic talent that they had working there. It saddened me greatly to see them consumed by Powersoft, and then Sybase.
Let's write some nVidia drivers in Java!
Weaselmancer
rediculous.
And this is precisely why Facebook requires 30,000 servers.
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