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
Japheth has a number of rather interesting projects that extend the functionality of DOS.
JEMM, which is his EMM386 replacement: http://www.japheth.de/Jemm.html
HX DOS Extender, which adds Win32 PE & basic API support to DOS to allow the execution of a whole array of apps: http://www.japheth.de/HX.html
We have Java!
Deleted
January 2010 is an exciting month for x86 assembly language developers.
I'm sure the two of them will be pleased.
Programming from the Ground Up
What's the difference between all of these different Assemblers? Aren't they all just x86, AMD64, or IA32
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.
What is primary use of assembly these days? I thought C gave you the same level of control, but with portability and much-improved readability.
And to give you an idea of where this question is coming from, the last app I wrote was a web app runs in JRuby, using DataMapper to free me from dealing with SQL and Sinatra to free me from dealing with HTTP/CGI. It runs on the Google App Engine cloud. My world is so high-level, with so many layers of virtualization and encapsulation, that I can barely see assembly way down there at the bottom of the stack...
A slashdotter who didn't build his own computer is like a Jedi who didn't build his own lightsaber.
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.
To answer your other question about benefits, most of the benefit comes from your toolchain. If you're using a toolchain that is designed to work with AT&T syntax, like GCC, then no, there's no benefit. If you want to interoperate with MSVC, there's a ton of benefit. (In particular, if you want to use inline asm in a MSVC program, it uses Intel syntax.)
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. :-(
Frankly, optimizing assembly code is a PITA, since there are so much different flavors.
For example, AMD and Intel processors have different types of optimization.
If I were to code in assembly nowadays, I'd prefer to use something like LLVM: http://llvm.org/ which should be able to generate good optimized code for any kind of processors, without the hassle of maintaining one routine per processor.
In some very extreme cases (like coding a RC5 decoder or multiprecision routines), it's still useful to use assembler, but in most other cases, I'm sure that LLVM is able to generate code much better than you could achieve manually in the same amount of time.
pusha
msg db 'Because I kinda like assembly.$'
mov ax, seg msg
mov ds, ax
mov ah, 9
int 21h
popa
mov ax, 4c00h
int 21h
nop
boycott slashdot February 10th - 17th check out: altSlashdot.org
It's far from cheap (let alone free) and it's not an assembler, but IDA Pro is indispensible for anyone who needs to develop, analyze, or debug code in assembler. It can't assemble code for you but it does everything else ( http://www.hex-rays.com/idapro/pix/idalarge.gif) you've thought of and many you haven't.
You can use compiler builtins for SIMD these days (fairly standardized across Intel, GNU, etc. compilers). (And don't complain about portability if you are using hand-coded SIMD....you have to be using #ifdefs or something anyway.)
Aside from using specialized instructions that are usually accessible from C anyway via builtins, it's not like x86 assembly has much relationship anymore to what actually happens in the hardware; you can't even control the real registers anymore (most CPUs have many more physical registers than are exposed in the instruction set, and rename on the fly).
Besides, most useful optimizations are much higher-level than that (besides the obvious question of algorithm choices, performance is typically dominated by memory access and you are better off focusing on locality than instruction-level efficiency).
If a thing is not diminished by being shared, it is not rightly owned if it is only owned & not shared. S. Augustine
I never got a five times speedup over Microsoft, but we consistently got 30% reduction in code size, which on a 640KB machine is not to be sneezed at. A big part of that was the excellent register calling conventions and pragma support.
The reality is that Watcom C++ was crushed by Microsoft Visual C++ which had a slick interface lashed onto appalling C++ language support. This was an era when anything slapped in a box was saleable software.
People forget that before eyeballs displaced profit, fatuousness displaced quality. It didn't matter very much if the feature worked as advertised. Software users, like deluded sports fans, believed that hope springs eternal. Maybe it would work in the next version? Sadly, programmers fell for the hype just as often as the end consumers. RIP Watcom.
The day Watcom packed it in—effectively about a version before their last release—I knew that quality had lost the race for many years to come. I didn't have it in me for a career in jello stacking, so I went off for a while to do my own thing. These days, quality is back on the table, for jobs that no longer exist. But if they did, it would be good times again.
Bill Watterson really knew what he was doing when he drew all those snowmen in the first half of the 1990s.