Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

x86 Assembler JWASM Hits Stable Release

ScuttleMonkey posted more than 4 years ago | from the need-more-assembler-nerds dept.

Programming 209

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."

cancel ×

209 comments

Sorry! There are no comments related to the filter you selected.

Just for some perspective... (5, Interesting)

tjstork (137384) | more than 4 years ago | (#30953980)

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.

Re:Just for some perspective... (3, Informative)

onionman (975962) | more than 4 years ago | (#30954176)

I'm also a big YASM fan. YASM can generate object files for Windows, OS X, and Linux. That, combined with its macro features, let you write a single x86 file that can be used on all three platforms.

I'll certainly take a look at JWASM, though!

Re:Just for some perspective... (1)

stupido (1353737) | more than 4 years ago | (#30955178)

In the past, I preferred NASM [www.nasm.us] for x86 cross platform development, meaning Win32 and Linux. It had decent support for the latest sets of instructions. The Microsoft syntax is something I prefer to avoid, so NASM was actually a plus in that respect, although some coworkers disagreed. There's a brief, but up-to-date comparison of x86 assemblers in Fog Agner's book [agner.org] . He says that YASM is better than NASM these days, and uses the same syntax. The Wikipedia page on Open Watcom Assembler [wikipedia.org] also has book reference that seemingly compares MASM vs. NASM vs. TASM vs. WASM, but it's from 2005.

xor my heart (4, Interesting)

RabidOverYou (596396) | more than 4 years ago | (#30954034)

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

Re:xor my heart (1)

mewsenews (251487) | more than 4 years ago | (#30954288)

i'm terrible with x86 assembly, is that the xor swap algorithm [wikipedia.org] ?

Re:xor my heart (1)

onionman (975962) | more than 4 years ago | (#30954394)

I believe it sets dx to the MSb of ax and ends up leaving ax unchanged.

Re:xor my heart (3, Informative)

onionman (975962) | more than 4 years ago | (#30954542)

I believe it sets dx to the MSb of ax and ends up leaving ax unchanged.

oops! I guess I'm getting my AT&T syntax and my Intel syntax confused. If it's Intel syntax, then:

cdw ;; copy MSb of ax to all bits of dx
xor ax, dx ;; if MSb of ax was 1 then flip bits of ax, otherwise, no effect
sub ax, dx ;; if MSb was originally 1, this will add 1 to the flipped bits. otherwise, no effect

So, assuming Intel syntax, this computes to absolute value of ax and sets all the bits of dx to be the sign bit

Re:xor my heart (1, Informative)

Anonymous Coward | more than 4 years ago | (#30954572)

Assuming that it is Intel syntax (as opposed to AT&T syntax) then this computes the absolute value of the signed value in ax and stores it in ax, while clobbering dx: // Note that with respect to 16 bit arithmetic, -x == ~x+1 for all x; the arithmetic negation of x is equal to one plus the bitwise negation of x for all 16 bit x.
cwd // Splats (repeats) the sign bit of ax to every bit of dx.
xor ax, dx // Do nothing if the sign bit of ax was zero; bitwise negate every bit of ax if the sign bit was one.
sub ax, dx // Do nothing if the sign bit of ax was zero; add one to ax if the bit was one.

Re:xor my heart (0)

Anonymous Coward | more than 4 years ago | (#30954458)

I think it's a branchless abs.

Re:xor my heart (2, Informative)

mparker762 (315146) | more than 4 years ago | (#30954526)

No, that snippet compares AL and DX, leaving AX with 1's everywhere except the first different bit, which will hold a 0.

Ex:
AL= 00001101
DX= 00000010 00011001

CWD just puts a 0 in AH
AX= 00000000 00001101
DX= 00000010 00011001

XOR ax,dx computes ax ^= dx
AX=00000010 00010100
DX unchanged

SUB ax,dx computes ax -= dx
AX=1111111111111011
DX unchanged

The XOR swap algorithm to swap ax and dx is:
xor ax,dx
xor dx,ax
xor ax,dx

Re:xor my heart (1, Informative)

clone53421 (1310749) | more than 4 years ago | (#30954916)

Incorrect. It converts AX to the absolute value of AX.

Re:xor my heart (2, Informative)

P-Nuts (592605) | more than 4 years ago | (#30954964)

Don't think that's quite right. As I said in my other reply, I had to look up CWD in the Instruction Set Reference:

The CWD instruction copies the sign (bit 15) of the value in the AX register into every bit position in the DX register.

So this means if AX was originally positive, nothing happens, and if AX was originally negative the XOR flips the bits of AX, then the SUB subtracts minus one from it (which is the same as adding one). This is the same as the two's complement unary minus operation. So the snippet computes the absolute value of AX, and stores the result in AX.

Re:xor my heart (1)

maxwell demon (590494) | more than 4 years ago | (#30956490)

CWD just puts a 0 in AH

Wrong on two counts:
First CWD is Convert Word to Double word (into DX:AX, because it's a 16 bit instruction; CWDE would extend AX into EAX). What you are thinking of is CBW.
Second, both CBW and CWD do sign extension; that is, they copy the most significant bit of the source (AL for CBW, AX for CWD) into the upper part of the destination (AX for CBW, DX:AX for CWD), so that when interpreted as (two-complement) signed value, the value is unchanged.

Re:xor my heart (1)

P-Nuts (592605) | more than 4 years ago | (#30954500)

That's a bit cruel. I had to look up CWD, but I presume there's not much need for it or it's CDQ/CQO brethren since the 16-bit days.

Re:xor my heart (1)

Waffle Iron (339739) | more than 4 years ago | (#30954976)

You also have to be really careful using instructions that update less than a full 32-bit register on modern X86s (such as these 16-bit instructions). You could get "partial register stalls" if you try to read the full-width EAX or EDX after such a sequence. That could toss a big wrench into the deep execution pipeline while the CPU hunts around amongst dozens of pending micro-ops for the appropriate contents of the upper half of the register.

Re:xor my heart (1)

paskie (539112) | more than 4 years ago | (#30954590)

I've never done anything really big in assembler but I'd say cwd is somewhat obscure thing, poor kid. :) I'd rather check if they understand what and how lea does, or some basic non-obvious test stuff.

([spoiler] So, am I completely stupid or is the snippet abs()?)

Re:xor my heart (2, Informative)

Rockoon (1252108) | more than 4 years ago | (#30954904)

cwd isnt obscure.. well, it wasnt in the 16-bit days.

The modern equivalent in 32-bit mode is cdq ..

These is absolutely necessary instruction when performing division, because on the x86 line division takes a double wide numerator from dx:ax in 16-bit, or edx:eax in 32-bit.

Re:xor my heart (2, Interesting)

TheRaven64 (641858) | more than 4 years ago | (#30954932)

Do you hire people who need to know obscure bits of x86 asm often, or is this just a way of catching people who exaggerate on their CVs?

Re:xor my heart (1)

elnyka (803306) | more than 4 years ago | (#30956384)

Do you hire people who need to know obscure bits of x86 asm often, or is this just a way of catching people who exaggerate on their CVs?

Probably the later, which is completely legit. It could be a bit uncalled for if the position the interview is for is, say, for developing web pages. But still, with something put on the resume, you take it (or put it) at risk. It would be very questionable, however, if a person is solely dismissed for passing a trivia, specially if it is not related to the job at hand (not that I'm accusing RabidOverYou of doing that, just sayin'...)

If you put something on your resume, you better be able to back it up technically in an interview. Or perhaps be a bit more careful and explicitly quantify what you know. .ie. expertise in MASM , or familiarity with X86 Assembly (TASM). Just saying "x86 Assembly" without quantifying the exposure and without explicitly stating the assembler/syntax, that could possibly open a can of worms.

We all taylor (or should taylor) our resumes (with truth facts, obviously) for specific job openings. What is always important is to be truthful (.ie. you "know" assembler), in a manner that is accurate and that does not come as a misrepresentation (you know it but it's been a long time back in school? Put in your "interests" or "hobbies" section, and not among your main skills.)

Re:xor my heart (2, Insightful)

elnyka (803306) | more than 4 years ago | (#30956424)

... plus a person willing to put "Assembly" in the resumes should be aware that it implies dexterity with binary arithmetic, bitwise ops, 2-s complements and all of that good shit.

Re:xor my heart (1)

creimer (824291) | more than 4 years ago | (#30956782)

The last time I put "assembly" (i.e., putting together lab benches) on my resume, someone asked me if I was a mainframe programmer. No. But I did some 6502 assembly on the Commodore 64 and could program a 68000 from the data book on paper. That didn't count.

Re:xor my heart (1)

clone53421 (1310749) | more than 4 years ago | (#30955022)

It took me a minute to remember what CWD does, but it converts a word (AX) to a dword (dx:ax).

So, if AX is positive, you have this:

dx:ax
0000:ax - cwd - zeros out DX
0000:ax - xor ax,dx - xors AX with 0000
0000:ax - sub ax,dx - subtracts 0 from AX

Whereas, if it’s negative, you have:

dx:ax
FFFF:ax - cwd - fills DX with 1s
FFFF:~ax - xor ax,dx - takes the bitwise complement of AX
FFFF:(~ax)+1 - subtracts -1 from AX

So in the end you have (~ax)+1, which is of course the absolute value of your original AX.

Re:xor my heart (2, Informative)

clone53421 (1310749) | more than 4 years ago | (#30955342)

the absolute value of your original AX

Come to think of it, that’s just in AX. DX contains the sign of AX.

I.e. it’s this, in terms of pseudo-code:
DX = sign(AX)
AX = abs(AX)

Re:xor my heart (1)

goga_russian (544604) | more than 4 years ago | (#30955892)

NOT al INC al rocket-launch.

Re:xor my heart (2, Interesting)

RicktheBrick (588466) | more than 4 years ago | (#30956082)

In the year 1973 I was employed by a company called Cascade Data. It was located in Cascade Michigan which was close to Grand Rapids. I was a computer programmer at the time. They manufactured computers that started with 16k bytes of magnetic core memory and could be double to 32k. They had a 5 Megabyte hard drive but most used a tape drive for storage. Input was from a typewriter like device as one would type in on a keyboard and the output was on paper. I wrote programs in both RPG and assembly languages. The computer was an eight bit processor so the registers were eight bits. This meant that the maximum number that a register could hold was 255. Just adding two numbers was fun since one would have to do add the least significant byte of one to its least significant byte of the other and than check for overflow and continue with the next byte. There were no multiply or divide instruction. To multiple 19 times 20 one would add 19 to a register 20 times. To divide 200 by 20 one would subtract 20 from 200 until one got a zero or negative number. It was not that much fun to program in assembly language but your program always took about half the memory that a RPG program did and with only 16k bytes of memory on some system, some programs just needed to be written in assembly. Unfortunately for me the company did not last very long as I was employed for only 6 months. The country fell into another recession and I got tired of looking for work so I went into the military. Today a 64 bit register will hold a number of 1.84 X 10 raised to the 19th power or at least 18 significant bytes so even the national debt would fit into one register. So it must be a little bit easier to program today than it was in 1973. After, I was asked to modify a existing program by one of their customers. They gave me two big boxes of computer cards and a printout of the program. I had to find the place where I wanted to modify the program and remove and replace the cards I needed to. Unfortunately two of the cards got interchanged and some time was spent troubleshooting it to locate the problem. I can only laugh when I think about it and how much easier it is today.

Re:xor my heart (1)

dwywit (1109409) | more than 4 years ago | (#30956418)

Ah, RPG - my first language after Apple basic. I nursed a suite of apps from RPGII on a System/36 through migration to an AS/400 (RPGIII), then re-written in ILE/RPG. I quite like that language. Perverse in this day and age, I know, but I had a lot of challenges and satisfaction - especially when it's the only compiler on the system.

Re:xor my heart (1)

null8 (1395293) | more than 4 years ago | (#30956670)

That's the 16bit abs() in x86. There are some variations on that, like cwd add ax, dx xor ax, dx I think the version you've written is patented by some russion guy at SUN, anyway, the fact, that you used 16bit version tells me you finished your colledge a while ago, since it a popular task in ours. Whe have to learn some x86 asm and do some primitive buffer overflow exploits at our university.

Japheth's Other Projects! (2, Informative)

Anonymous Coward | more than 4 years ago | (#30954052)

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

Re:Japheth's Other Projects! (1)

Dwedit (232252) | more than 4 years ago | (#30954136)

Note: NOT the same JEMM that came with Privateer.

Re:Japheth's Other Projects! (1)

UnknownSoldier (67820) | more than 4 years ago | (#30956030)

:-( Thanks for clarifying though.

Re:Japheth's Other Projects! (5, Funny)

glwtta (532858) | more than 4 years ago | (#30954312)

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.

Re:Japheth's Other Projects! (1)

TheRaven64 (641858) | more than 4 years ago | (#30954734)

HX DOS Extender, which adds Win32 PE & basic API support to DOS

I wasn't quite sure what you meant by this, because what you seemed to imply it did seemed just too wrong to exist, but it turns out that it really is a DOS extender that comes with partial Win32 support. Yes, you can now run DOSBox under DOS (and a lot of other single-window Windows apps; it probably wouldn't be too hard to add a windowing system either, but that would be far too wrong). Now all he needs to do, I guess, is add a POSIX layer...

Who needs JWASM? (2, Funny)

Colin Smith (2679) | more than 4 years ago | (#30954098)

We have Java!

 

Re:Who needs JWASM? (1)

binarylarry (1338699) | more than 4 years ago | (#30954148)

I think you just had a JWASM!

Hey that's great (4, Funny)

Weaselmancer (533834) | more than 4 years ago | (#30954468)

Let's write some nVidia drivers in Java!

Java, C#, Lisp, Smalltalk, Forth (0)

Anonymous Coward | more than 4 years ago | (#30957076)

Let's write some nVidia drivers in Java!

To be serious for a moment, it is certainly possible to write large portions of device drives in a higher level language:

Java
http://en.wikipedia.org/wiki/JNode
http://en.wikipedia.org/wiki/JX_(operating_system)
http://en.wikipedia.org/wiki/JavaOS

C#:
http://en.wikipedia.org/wiki/Singularity_(operating_system)

Lisp:
http://en.wikipedia.org/wiki/Genera_(operating_system)

Smalltalk:
http://www.lesser-software.com/en/content/products/LSWVST_Smalltalk_os.htm

Forth:
http://en.wikipedia.org/wiki/Open_Firmware

Re:Who needs JWASM? (1)

Tumbleweed (3706) | more than 4 years ago | (#30955614)

JWASM

JWASM is JaWa-asm, and is very useful for programming droids (the non-cellphone kind).

Re:Who needs JWASM? (1)

iluvcapra (782887) | more than 4 years ago | (#30957300)

I detest it, filthy creature. Then again it has some carbon scoring, it mist have seen a little action...

An exciting month for who? (5, Funny)

Anonymous Coward | more than 4 years ago | (#30954100)

January 2010 is an exciting month for x86 assembly language developers.

I'm sure the two of them will be pleased.

Re:An exciting month for who? (2, Funny)

Chapter80 (926879) | more than 4 years ago | (#30954808)

The first thing I'm going to do with this new assembler is to write a C compiler, and then write Python in C, and then I can get down to work...

Re:An exciting month for who? (1)

obarel (670863) | more than 4 years ago | (#30956074)

Don't forget the web framework in Python to be able to get anything done.

Re:An exciting month for who? (1)

RCL (891376) | more than 4 years ago | (#30956264)

You are obviously not coding stuff that pushes hardware to its limit. But well, clerks of the programming are also needed and are probably well paid.

Re:An exciting month for who? (1)

whoop (194) | more than 4 years ago | (#30957056)

What, no port of JWASM written in assembler first?

Programming from the Ground Up (3, Informative)

omar.sahal (687649) | more than 4 years ago | (#30954142)

Or you could use gcc

Programming from the Ground Up [igsobe.com]

I highly recommend working through this book even if you'll never program assembly again... you'll be a vastly better programmer. -- Joel Spolsky, JoelOnSoftware.com

Re:Programming from the Ground Up (1, Funny)

Anonymous Coward | more than 4 years ago | (#30954344)

joel does all his work in vb. Not vb.net, vb. His endorsement is kind of useless.

Re:Programming from the Ground Up (1)

xZgf6xHx2uhoAj9D (1160707) | more than 4 years ago | (#30956640)

And yet as horrific as that tidbit is, it somehow managed to raise my opinion of him. I'd consider the opinion of my cat to be more credible than that of Joel Splosky on anything programming related.

JWASM? (0)

Anonymous Coward | more than 4 years ago | (#30954168)

JISM!

I'll ask it (2, Interesting)

jgtg32a (1173373) | more than 4 years ago | (#30954332)

What's the difference between all of these different Assemblers? Aren't they all just x86, AMD64, or IA32

Re:I'll ask it (4, Informative)

TheRaven64 (641858) | more than 4 years ago | (#30954780)

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.

High level languages :P (-1, Troll)

Anonymous Coward | more than 4 years ago | (#30954426)

It is 2010. Computers are fast enough for you to leave assembler and pick up a more modern environment, such as C.

Watcom, I cry for thee. (5, Interesting)

Anonymous Coward | more than 4 years ago | (#30954442)

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.

Re:Watcom, I cry for thee. (1)

Colin Smith (2679) | more than 4 years ago | (#30955856)

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.

This is the big benefit of Capitalism. You produce something good, it rocks the boat, then you get bought over and buried. It's the natural order.

 

Excited x86 assembly developers (1)

yorgasor (109984) | more than 4 years ago | (#30954494)

"January 2010 is an exciting month for x86 assembly language developers"

Somehow I have a hard time imagining a bunch of x86 assembly programmers getting excited. I've done assembly on a lot of different architectures, and I can't say "excitement" was ever a term I'd use to describe any emotions related to it.

"Oh wow! There's a new tool that might make some poor saps lives suck slightly less! This is such an awesome month!"

Re:Excited x86 assembly developers (1)

dreamchaser (49529) | more than 4 years ago | (#30954574)

I dunno. The first time I successful assembled the code to boot my '386 into protected mode, spawn a task, print 'Hello, World.' to the screen, then gracefully exit I was rather excited. I was close to 20 years younger then and had less of a life though.

Mostly off topic question about ASM on x86 (1)

BitZtream (692029) | more than 4 years ago | (#30954962)

I've done that on ATmega processors, but not x86. With x86 hardware so cheap now, the only reason I have to use ATmega's is power savings, but the loss of CPU power makes it not worth it for my toying around.

I'm interested in doing exactly what you did 20 years ago. Would you know of a decent place to find the documentation required to do this? Like info on video output and such? Just a general basic getting started website or even a book, I don't mind buying something for the knowledge.

I'm a C guy, but as I've said I've done SOME asm for other processors, I just want something with an MMU, and since I can fire up a virtualbox/vmware/parallels machine rather than use actual hardware, x86 seems like the easiest solution.

An alternative would be if anyone knows of a ARM emulator for Windows or preferably OSX that could simulate this sort of thing as well. It'd need to emulate an ARM with an MMU at least, and I don't think theres any 'standard' way of doing video and such on arm, unlike the 'standard pc' kind of thing you can go with on x86 since thats pretty much what all the embedded boards act like anyway.

With the Atmel stuff you have a great emulator to see whats going on with the chip, I don't know of anything like that for x86 other than GDB, is there any sort of 'ASM for cluebies' setup for x86 that would compare to the Atmel IDE/simulator/debugger?

Re:Mostly off topic question about ASM on x86 (1)

TheRaven64 (641858) | more than 4 years ago | (#30955488)

You should probably take a look at QEMU. It can emulate a variety of platforms, including a couple of ARM chips with various peripherals. Or a SPARC workstation, or a PowerPC system. And, of course, x86. It will boot these from a ROM image, so you can easily give it your binary to load with no OS, if that's what you want.

Re:Excited x86 assembly developers (1)

TheRaven64 (641858) | more than 4 years ago | (#30954800)

Of all CPU architectures, I think x86 assembly is exciting. In the same way that crossing a rickety bridge over a pit of lava is exciting...

why? (3, Interesting)

Lord Ender (156273) | more than 4 years ago | (#30954502)

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...

Re:why? (4, Insightful)

Anonymous Coward | more than 4 years ago | (#30954680)

And this is precisely why Facebook requires 30,000 servers.

Re:why? (4, Informative)

Anonymous Coward | more than 4 years ago | (#30954730)

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).

Re:why? (4, Informative)

TheRaven64 (641858) | more than 4 years ago | (#30954982)

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.

Re:why? (1)

TheRaven64 (641858) | more than 4 years ago | (#30954890)

Not everything is exposed to C. C is designed for PDP-11s. It doesn't have any of the more advanced CPU features. If you want to use any privileged instructions (required for writing an OS), if you want to use SIMD units, if you want to use things like population count instructions, then you can't use portable C.

This doesn't always mean that you have to use assembly. Most instructions are exposed via platform-specific intrinsic functions. The code generator in the C compiler will handle register allocation for you, but will use the correct instruction. Often these also come with fall-back for other platforms (e.g. call a library function to swap byte order if there is no BSWAP instruction).

Re:why? (0)

Anonymous Coward | more than 4 years ago | (#30954900)

And in JRuby how would you use a new asm instruction in that new CPU to get that 40x speedup?

Right too right job...

Also there are MANY times a compiler will pick a very strange sequence of asm. That is crazy slower. Compilers are good. But when you need that little extra umph you crack out the asm.

Compilers are fairly restricted in what asm codes they will emit. As they try to hit the sweet spot on all cpus. But some cpus do better with other sequences than others.

The only reason you are where you are is because you are standing on the backs of the code that does crazy things with asm.

Re:why? (0)

Anonymous Coward | more than 4 years ago | (#30955264)

Microcontrollers, applications that interface directly with hardware (outside of the c world).. and just about everything that you don't program.
Before the web which seems to be your world, there was C, C++, and Assembler. The two worked together, in a lot of cases.
Now, in todays world there are admittedly less desktop-based assembler coders. That being said, assembler is widely used in non-desktop based situations for more customized situations.

Java, Ruby, HTTP/CGI are all interpreted. (in the case of a C cgi application, that's different) Something else runs the interpreted code. Assembler in it's rawest form is under everything, so to speak.

Re:why? (1)

Lord Ender (156273) | more than 4 years ago | (#30955328)

Listen, I have a PIC Microcontroller here on my desk. I toy with it from time to time, to build my killer robot... but even that wimpy little 8-bit fleck of baked sand can be programmed with C.

And I am aware that the languages I do useful (non-killer-robot) work in all run on top of something which runs on top of something (etc.) which was programmed in C.

My question is: who out there is saying "gee, C just won't cut it. I need assembly."?

Re:why? (1)

Grishnakh (216268) | more than 4 years ago | (#30955452)

I still program my PICs in assembly. However, I'm using the really tiny ones (PIC12F510). I also haven't found a convenient C compiler for them that runs in Linux, but the gpasm, gpsim, and pk2 utilities work just fine for me in Linux.

Re:why? (0)

Anonymous Coward | more than 4 years ago | (#30955702)

i thought that was answered already. OS Programmers. thats who. i believe a lot of programmers that write drivers use assembler also.

Re:why? (1)

Grishnakh (216268) | more than 4 years ago | (#30955492)

There's a couple of places:

1) Really tiny microcontrollers with 100 bytes of RAM. These are pretty easily programmed in assembly, though, because there's just not that much to do. However, this isn't affected by this news, since these microcontrollers are most certainly not x86-architecture.

2) The Linux kernel has a little bit of assembly for some low-level hardware initialization stuff. However, for the x86 stuff, they seem to be getting along just fine with nasm. Why anyone would care about a different assembler whose only advantage is its syntax, I have no idea. It's not like there's anyone doing a lot of work with x86 assemblers any more.

Re:why? (1)

calzakk (1455889) | more than 4 years ago | (#30955884)

In short, speed.

I did a little assembly some years ago. I was writing an image processing algorithm in C which was taking something like 10ms, which just wasn't good enough. So I rewrote it in x86 assembly, and got it down to 2ms or so. But, wanting to go even further, I rewrote it using MMX and got it down to well under 1ms. Much faster than the original C code, so much more useful.

Assembly's still used of course, but most people don't even know it's there. We've just been spoiled with lazy high-level languages (C#, Java), faster hardware, and better compilers.

not needed for MMX anymore (3, Insightful)

stevenj (9583) | more than 4 years ago | (#30957196)

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).

Re:why? (1)

EzInKy (115248) | more than 4 years ago | (#30956714)

In addition to what others have said, it's helpful for compiler programmers to have a little knowledge of assembler too.

And how does it differ ? (1)

alvieboy (61292) | more than 4 years ago | (#30954528)

Pretty much all of assemblers I know work the same way (despite syntax). You can also add macro functionalities to some, using external preprocessors.
So, if anyone can elucidate me, how does this MASM differ from NASM ? And how does its syntax differs from NASM and AT&T ?
I use AT&T syntax a lot (gas), embedded in gcc (for microcontrollers). Do I get any real benefit by using other variants? If so, which benefits ?
Alvie

Re:And how does it differ ? (5, Informative)

EvanED (569694) | more than 4 years ago | (#30954726)

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 [imada.sdu.dk] 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.

Re:And how does it differ ? (2, Informative)

EvanED (569694) | more than 4 years ago | (#30954774)

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.)

Re:And how does it differ ? (1)

Rockoon (1252108) | more than 4 years ago | (#30955380)

NASM was a good effort, but in the end its just a simple assembler with a few preprocessor features bolted on. Nobody points to NASM and declares "thats a great feature other assemblers should have" aside from its open source nature.

There are many other x86 assemblers that are in the same boat as NASM. They are just simple assemblers.

MASM is all about the macro language. While terribly hard to learn to do more advanced macro stuff due to the way it evolved (feature creep while maintaining compatibility), it is extremely powerful and in many ways (other than syntax) it is like having javascript for a preprocessor language (for instance, a macro can return another macro that was completely generated at assemble-time)

Most assembly programmers mix with high level languages. They are essentially library programmers in asm land and application programmers in high level language land.

So what? (-1, Flamebait)

frank_adrian314159 (469671) | more than 4 years ago | (#30954598)

JWASM is a welcomed tool that supplements the entire x86 assembly language community...

In Korea, only old people use assembler.

Re:So what? (0)

Anonymous Coward | more than 4 years ago | (#30955094)

Korea's not exactly the cutting edge of coding, either...

Flat Assembler? (1)

Futurepower(R) (558542) | more than 4 years ago | (#30954642)

How does JWASM compare with Flat Assembler? [flatassembler.net]

In Soviet Russia (0)

Anonymous Coward | more than 4 years ago | (#30954722)

JWASM assembles you!

RTFA while you can. It's going to be deleted... (1)

stupido (1353737) | more than 4 years ago | (#30954794)

from Wikipedia as "non-notable". It's already tagged for deletion there. The OP should get some award for posting a story with a link that will die on its own instead of the usual Slashdot Effect.

Wikiwars (5, Informative)

SarekOfVulcan (133772) | more than 4 years ago | (#30954844)

Be warned -- JWASM's Wikipedia article was nominated for deletion [wikipedia.org] , as it was thought that notability was not sufficiently asserted. The flame war there might spill over here as well. :-(

Re:Wikiwars (1)

stupido (1353737) | more than 4 years ago | (#30955654)

The deletion discussion is far, far longer than the article itself. This [encycloped...matica.com] seems a good description of the guys spending their time that way.

Re:Wikiwars (5, Insightful)

Just Some Guy (3352) | more than 4 years ago | (#30956182)

Be warned -- JWASM's Wikipedia article was nominated for deletion

And that right there's why I won't donate a penny to that project. Honestly, WTF? That article's source is about 13KB long. At $100/TB, it costs about 1/7800th of a penny to store. "But what if it clutters up the site!", say the Deletionists. Apparently there's an alternate front page to Wikipedia that lists every single article and it's critical that it be kept tidy and short.

Actually, I take that back: can I send Wikipedia a penny and sponsor a few thousand articles of my choosing, starting with this one?

Re:Wikiwars (2, Interesting)

stupido (1353737) | more than 4 years ago | (#30957176)

"Deleted" articles don't get deleted from the Wikipedia database at all. They just get hidden from the public. An administrator can undelete them at any time. So, there's no monetary saving involved. Arguably, plain spam should be removed from the site, but JWASM is obviously not that. It is even discussed in Fog Agner's book, which normally meets the requirements for a Wikipedia article. See my post [slashdot.org] above. I can't be bothered to read the insanely long deletion discussion to see why that's not enough for them. What's more funny is that they now argue that having a Slashdot story doesn't matter because popularity is not the same as "notability". Go figure.

OMG (1, Redundant)

SpaghettiPattern (609814) | more than 4 years ago | (#30955050)

January 2010 is an exciting month for x86 assembly language developers.

What? You mean both of them?

Re:OMG (1)

shutdown -p now (807394) | more than 4 years ago | (#30955368)

Um, so who's the other guy?

LLVM (2, Informative)

eulernet (1132389) | more than 4 years ago | (#30955100)

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/ [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.

Re:LLVM (1)

TheRaven64 (641858) | more than 4 years ago | (#30955598)

If I were to have to write something in assembly, I'd hate to have to use LLVM (and I've written two compilers that use LLVM on the back end and have commit access to LLVM). Writing static single assignment code is absolutely no fun. Beyond that, there's almost nothing that you can do in LLVM that you can't do in C (the LLVM intrinsics are all exported as C intrinsics in clang), the only exception is setting up DWARF unwinding tables, and, having written code to do that for two high-level languages, I would absolutely hate to have to do it by hand myself for every function.

That's good news (2, Interesting)

bl8n8r (649187) | more than 4 years ago | (#30955350)

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

Re:That's good news (3, Insightful)

clone53421 (1310749) | more than 4 years ago | (#30955432)

You forgot to jump around your message, or put it at the end, or use segments to tell the assembler to do that automatically.

Re:That's good news (1)

maxwell demon (590494) | more than 4 years ago | (#30956254)

I just ran the text through ndisasm, and that's what I got (actually there's an extra 0A from the line end; this would actually be the first byte of the mov instruction after the text; of course, the meaning of the other instructions would be changed as well by this.

00000000 42 inc dx
00000001 65636175 arpl [gs:bx+di+0x75],sp
00000005 7365 jnc 0x6c
00000007 204920 and [bx+di+0x20],cl
0000000A 6B696E64 imul bp,[bx+di+0x6e],byte +0x64
0000000E 61 popa
0000000F 206C69 and [si+0x69],ch
00000012 6B652061 imul sp,[di+0x20],byte +0x61
00000016 7373 jnc 0x8b
00000018 656D gs insw
0000001A 626C79 bound bp,[si+0x79]
0000001D 2E240A cs and al,0xa

Re:That's good news (1)

SignoffTheSourcerer (567014) | more than 4 years ago | (#30957226)

And my alltime favorite: rep jmp cx

IDA Pro (2, Interesting)

mpsmps (178373) | more than 4 years ago | (#30955562)

It's far from cheap (let alone free) and it's not an assembler, but IDA Pro [hex-rays.com] 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 [hex-rays.com] ) you've thought of and many you haven't.

Assembler (1)

should_be_linear (779431) | more than 4 years ago | (#30955592)

I used to program anything serious in assembler until, say, 1991. Then I moved to C++/Pascal, but always hand-tuned critical parts with Assembler. Around 1995 I realized compilers are doing better job in optimization of those critical parts then my hand-crafted assembly code. I think currently it is only useful for SIMD instructions and similar cases where it is hard for compiler to figure parallel data manipulation with specialized instructions. With ongoing improvements in compilers, those will go away too, right? Or is there anything compilers definitely cannot figure out?

you haven't needed asm for SIMD for years (1)

stevenj (9583) | more than 4 years ago | (#30957038)

GNU, Intel, etcetera have compiler builtins for SIMD instructions that are usable directly from C.

Can anyone recommend a good interactive tutroial? (1)

metrix007 (200091) | more than 4 years ago | (#30955784)

Would really like to understand the underlying hardware better, but have found the concepts difficult so far.

Can anyone recommend a good perhaps interactive tutorial that explains these concepts?

marketing promo (0)

Anonymous Coward | more than 4 years ago | (#30956156)

This story has only been submitted as a last-ditch attempt to argue for the company's notability on Wikipedia. As such, I encourage slashdot to take down the article as it is a marketing-promo.

So much fun (0)

Anonymous Coward | more than 4 years ago | (#30957182)

I had so much fun reading your comment guys. I start to understand what "normal" people feel when I talk about programming. And I mostly do Ruby and Python sometimes C. Continue to have fun with asm x86, we need you guys !

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>