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

Comments

Just for some perspective...

[tjstork]

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

[onionman]

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

[stupido]

In the past, I preferred NASM 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. He says that YASM is better than NASM these days, and uses the same syntax. The Wikipedia page on Open Watcom Assembler also has book reference that seemingly compares MASM vs. NASM vs. TASM vs. WASM, but it's from 2005.

Re:Just for some perspective...

[yuhong]

VC2010 will fix this: https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=371743&wa=wsignin1.0

Re:Just for some perspective...

[larpon]

f*** youuuu dolphin!!

Re:Just for some perspective...

[Anonymous Coward]

I doubt that you actually program in assembler, but I am quite certain that the curtains your rather stern looking wife picked out for your rented home have little swastikas on them. Love and kisses from your gay admirer.

xor my heart

[RabidOverYou]

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

[mewsenews]

i'm terrible with x86 assembly, is that the xor swap algorithm?

Re:xor my heart

[onionman]

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

Re:xor my heart

[Anonymous Coward]

I think it's a branchless abs.

Re:xor my heart

[P-Nuts]

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

[mparker762]

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

[onionman]

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

[Anonymous Coward]

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

[paskie]

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

[Rockoon]

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

[clone53421]

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

Re:xor my heart

[TheRaven64]

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

[P-Nuts]

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

[Waffle Iron]

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

[clone53421]

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

[clone53421]

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

[goga_russian]

NOT al INC al rocket-launch.

Re:xor my heart

[RicktheBrick]

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

[elnyka]

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

[dwywit]

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

[elnyka]

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

[maxwell demon]

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

[null8]

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.

Re:xor my heart

[__aaclcg7560]

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

[RobDude]

Possibly off-topic - but - can anyone tell me if there is much demand for x86 assembler developers?

I'm a 'cookie cutter' .Net Developer. From what I understand, I'm pretty much a dime a dozen....I'm thinking of trying something new.

Re:xor my heart

[Anonymous Coward]

Reminds me of something fun during an interview... I interview some guy for a Job at a startup developing applications for mobile devices. His CV says he did C#, Java but also C, assembly, etc. so I ask a few questions about Java and he goes "oh I did some of these but I'm a low-level guy, I'm good at optimizing things in C and assembly" (supposedly he had been working on some Uni project, optimizing a ray-tracer or something, I don't remember his resume)...

Me: "Oh so you know assembly well?"
Him: "yes, very well"
Me: "On what kind of CPUs have you programmed in assembly?"

After my question, he instantly turned red. The only time I've seen someone turn red faster than that was the day I busted a girlfriend who had cheated on me ;)

Re:xor my heart

[epine]

Amazing how rusty the pipeline-stall instruction group becomes after twenty years of disuse. CWD is a little outside the nucleus of RISC instructions screaming to break free. Not the inner circle of hell, but one of the antechambers. More worth forgetting than recollecting.

The true lesson of our x86 heritage: discretion is the greater part of valour. There's a *lot* of aging x86 instructions that belong to the HCF group for all practical purposes.

Re:xor my heart

[Anonymous Coward]

CWD is Convert Word to Doubleword, and the 16 bit era used DX:AX as the doubleword. GP was thinking of CBW, Convert Byte to Word, which sign extends AL to AX. But yeah, you got it, and are almost ready to start learning how to code for the 386.

Re:xor my heart

[Anonymous Coward]

And then I get to watch the color drain from your face when I tell you that:

xor ax, ax
cwd
xor ax,dx
sub ax,dx

results in zero, and that your code is relying on a non-zero value in the AX register in order to do anything useful.

Re:xor my heart

[Anonymous Coward]

Well, absolutely neccesary is going a bit far when

mov dx,ax
sar dx,16

does the same. But yeah, using dx:ax and edx:eax is one of the slightly less idiotic design decisions out of the hundreds of fucking stupid headache inducing design choices in the x86 line. Going from 68k asm to x86 was horrible. It's better nowdays, plenty of registers etc. but it took its sweet time getting there.

Re:xor my heart

[uncqual]

Remarkably, it's my understanding that sometime between 1973 and 2010 some HTML tags such as <BR> and <P> were introduced. I've also heard these can even be used to format comments on /.

Re:xor my heart

[Anonymous Coward]

Huh? abs(0) = 0

Re:xor my heart

[Anonymous Coward]

Did you know that you can use the "extrans" formatting option to escape HTML tags? The downside is that you can't use URLs, lists, or text formatting (old AKA , (teletype), talics), but you didn't use those in your post.

Re:xor my heart

[Anonymous Coward]

One could avoid shifting as follows:

mov dx, ax // We do not want to lose the value in ax.
add dx, dx // Put the most significant bit in the carry flag.
sbb dx, dx // Subtract the carry flag from zero and put it in dx.

Re:xor my heart

[Myria]

I see your x86 absolute value trick and raise you my MIPS absolute value trick:

bgtz a0, label
label:
subu a0, zero, a0

Re:xor my heart

[i.of.the.storm]

So, we only learned MIPS in school. Why does x86 have different syntaxes? Do different assemblers just have different psuedoinstructions or something? That seems a bit kludgy to me...

Re:xor my heart

[ByteSlicer]

So this means if AX was originally positive, nothing happens

Not quite correct: in that case the zero sign bit is extended into the DX register, clearing it.

Re:xor my heart

[snemarch]

Different platforms have different instruction sets, and thus different mnemonics. As for operand order, Intel follows the C style of "dst, src", whereas AT&T tries to follow English rules ("mov src, dst" -> move source into destination) which looks plain wrong to us people used to Intel syntax :)

Furthermore, there's also a bit of mnemonic difference on the same platform, at least between GAS and "most everybody else" - GAS wants operand size as part of the instruction mnemonic instead of deducing it from arguments.

Re:xor my heart

[Rockoon]

"sar dx, 16" wasnt a valid 8086 instruction. The ability to use a constant larger than 1 wasnt introduced into the 80286. Prior to that, you would have had to use the cl register:

mov dx, ax
mov cl, 16
sar dx, cl

damn i'm old.

Re:xor my heart

[xZgf6xHx2uhoAj9D]

More precisely, AT&T tries to follow Unix order, not English order. Things in Unix (e.g., the ln command) consistently have the destination last.

Re:xor my heart

[Opportunist]

I feel your pain. I'm in a similar position, but it's even a bit more specialized. I need people who have experience with reverse engineering and no criminal background (i.e. are not only good reversing...). And are available. And that includes being able to read and understand asm code written by someone else. Worse, asm code that a disassembler created. Which is mostly straightforward, granted, since high level languages create fairly easy assembler code. Still, there's always that odd debugger trap and a few knuckleballs thrown at you during analysis that you have to be able to dodge.

My favorite question (and I'm sure it will make my troll emerge from the depths again since he always surfaces when I get that example online at /.) is still

pop ebx
inc ebx
push ebx
retn

What would it do? Note that it is not a standalone snippet but a subroutine call'ed by the main program (which the retn alone should give away, but I usually tell an applicant). It's a fairly easy snippet and you encounter such stack manipulation tricks a lot. Sometimes nested a few times with a few registers popped and only the last one maniuplated, but it shows me immediately if the applicant knows a bit about subroutines in assembler and how they are handled by the x86 CPU.

About your example, I have to admit, I'd have had to look up the way cwd works. It might surprise you, but even though I have to use asm on an almost daily base, it has been quite a long while since I encountered a cwd, probably because dwords can be handled much easier today. popads are more common in my field of work, and knowing in what order the registers are filled is probably more important for me than to know an instruction that died out when 32bit became the norm.

Ok, that was unfair. Died out is probably wrong to say in a langugage that only exists anymore in very specialized fields and for special cases. I could not really see a sensible use in a modern CPU able to handle dwords natively in its registers, but maybe there is an application for the field you're in.

Re:xor my heart

[Briareos]

Except, of course, that shifting is basically free but is only one extra instruction, not two.

Re:xor my heart

[x2A]

aww did it hurt your poor little eyes, did having to move them around so much leave you out of breath? Go take a jog or something, fatty.

Re:xor my heart

[i.of.the.storm]

Duh, I know what instruction sets are. I don't expect MIPS and x86 to have the same operand order, but I'm just surprised that there are assemblers that use different operand order. I guess the Intel style is closer to what I expect from MIPS I guess.

Re:xor my heart

[RabidOverYou]

No one reads old SlashDot threads...

Yes, it's AX=ABS(AX).

I certainly wouldn't ding someone for not ripping though the answer - it's way too obscure. I've no problem explaining what each instruction does. But after that, it's pretty good at showing a thought process. Go get off my lawn, but dammit I think any geek should understand bits and bytes, and enjoy them. So even if they don't crank it out, I'd get a sense of the candidate, whether they thought the problem was pretty cool or a waste of time.

I once heard of some compiler geeks writing a program to find these code snips. "Gee, what five-or-fewer x86 instructions would perform x?" You supply a dozen inputs/outputs, the program tries all permutations of instructions, sees if In gives Out, Bob's yer uncle. The story (or legend) says the proggy shook out one or two new ones. If you don't think that's nifty, you're No Hire to me.

-- Rabid

Re:xor my heart

[Pseudonym]

What would it do?

It would cause the biggest pipeline stall you've ever seen.

Re:xor my heart

[snemarch]

Operand order depends on assembler, not platform :)

Re:xor my heart

[x2A]

"I once heard of some compiler geeks writing a program to find these code snips"

'Genetic algorithm's are one way of doing it that sounds most interesting. Run your loads and loads of snippets of code, collecting those that work (or those that closest to work) and those that don't... then "mate" them; so you produce a second generation, swapping over bits of code from one with code another, and run that, keeping the best and going for a third round. Occasionally, just flip a random bit in a code block, which will be your 'mutation', and if that crashes, causes an illegal instruction fault, infinite loops etc etc, you bin it. Occasionally, one will improve it, and so you keep it. Repeat ad nauseum! After 50,000 generations, you end up with something far better than you could've just written yourself (although this may only really apply to larger algorithms than an abs call).

I believe that there are jet engines out there "designed" in this way, where the efficiency of the engine wrt airflow etc etc is beyond what the creators of the system that produced it could even understand themselves. I think as computers get more powerful, biological processing, either simulated/abstracted (as above) or actually real biology could play a big role in our progress

Re:xor my heart

[x2A]

How big will the stall really be? Seems with register renaming isolating the bit of code from any uses of EBX,ESP,EIP outside of the code, and the original RETN address will most likely be in the processor waiting to be written out (depending on any relevant MTRR flags etc) and clever enough register/memory renaming (which I /assume/ modern processors are doing) can have aliased EIP to [ESP+x] to EBX by the time the RETN instruction has gone through the DECODE stages, so as soon as INC EBX is executed, it knows the register that's holding the value that EIP will be after the RETN is executed is incremented too, throwing out instructions past the RETN that've been speculatively LOAD/DECODEd, causing the new instructions to enter the start of the pipeline while the PUSH EBX is in execution (probably quickly too, as the memory at the location will most likely already be local), so after RETN there will be a small delay until the new instruction gets to the EXECute stage.

Of course I know this is drastically simplified, relies on the processor being able to set up aliased register dependancies in the DECODE stages, and is ignoring the multiple execution units that without the INC EBX could be executing more instructions at the same time... am I wrong in assuming that register/dependancy aliasing can occur in in DECODE? It's been such a long time I looked at CPU internals, I remember where they were, I'm just assuming that by now they can do that *lol*

Re:xor my heart

[Pseudonym]

Modern instruction prefetch units keep a cache of return targets. (I don't know for sure, but if I were a CPU designer, which I'm not, I experiment with flushing it when a likely context switch has occurred, e.g. loading the TR or modifying CR3.) The IPU is going to assume that you're returning from whence you came until it discovers otherwise. This will almost certainly be a cache hit, but at that point a large part of the pipeline will have to be flushed.

You could design a CPU that treats this case better, but you have to ask if it's worth going to the trouble.

Re:xor my heart

[clone53421]

Correct. In the end, DX contains either 0000 or FFFF: 0 or -1, the sign of AX originally.

Re:xor my heart

[clone53421]

Don’t forget DX = SGN(AX).

Doing both at the same time... yeah, I thought it was pretty cool.

Re:xor my heart

[clone53421]

your code is relying on a non-zero value in the AX register in order to do anything useful.

No. The output (zero) when AX was zero is still useful.

Re:xor my heart

[x2A]

Well there's no context switching going on here as it's only a near return, so in effect it translates to a dynamic jump (or a register load, with that register being EIP) and a register increment (ESP) which seems like it would be worth optimising considering what's involved and what's already available in the CPU... you're still going to get some pipeline flushing whatever happens, but the question is where that begins; with aliased register and memory dependancy tracking required already for speculative execution, the processor can know the target for the RETN by the time INC EBX has left the execution unit... ah... tho they've very close here... I guess as modern CPUs issue more and more instructions per clock, the RETN could already be executing at the same time as the INC EBX, or be at the most a single clock away... so yeah in that case you're right, as all optimisations in the world are irrelevant if the change to the jump address occurs in the same clock as the jump.

Hmm, I wonder how one would go about implementing some think-ahead *lol*

Japheth's Other Projects!

[Anonymous Coward]

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!

[Dwedit]

Note: NOT the same JEMM that came with Privateer.

Re:Japheth's Other Projects!

[glwtta]

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!

[TheRaven64]

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

Re:Japheth's Other Projects!

[UnknownSoldier]

:-( Thanks for clarifying though.

Re:Japheth's Other Projects!

[richlv]

can you run wine for windows in it ?

Re:Japheth's Other Projects!

[snemarch]

This is (or well, was) more useful than it sounds at first: back in the days, you pretty much had two choices for 32bit dos-extended C++ programming. Either Watcom C++ (the de-facto standard), or Borland C++ with the dos-extender add-on pack (which didn't come default). Using a 3rd-party PE-console supporting dos extender (the first one I came about was WDOSX, well before HX) let you use whatever Win32-supporting compiler for producing 32bit dos apps, including Borland C++ without the dos-extender pack, Visual C++, et cetera.

Re:Japheth's Other Projects!

[clone53421]

Yes, you can now run DOSBox under DOS

I don’t have DOS, I only have Windows. Can I run DOSBox under DOS with the HX DOS Extender in DOSBox under Windows?

Who needs JWASM?

[Colin Smith]

We have Java!

 

Re:Who needs JWASM?

[binarylarry]

I think you just had a JWASM!

Re:Who needs JWASM?

[Tumbleweed]

JWASM

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

Re:Who needs JWASM?

[iluvcapra]

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

An exciting month for who?

[Anonymous Coward]

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?

[Chapter80]

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?

[obarel]

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

Re:An exciting month for who?

[RCL]

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?

[whoop]

What, no port of JWASM written in assembler first?

Programming from the Ground Up

[omar.sahal]

Or you could use gcc

Programming from the Ground Up

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

[Anonymous Coward]

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

Re:Programming from the Ground Up

[xZgf6xHx2uhoAj9D]

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.

Re:Programming from the Ground Up

[Anonymous Coward]

That's not from the ground up. This is from the ground up. There's a course and some videos on the net built on this named "from NAND to tetris". I think I saw a curriculum somewhere, where the students actually started by going to the lab to make a single NAND gate with lithography, then do the rest of the course with simulated gates.

JWASM?

[Anonymous Coward]

JISM!

I'll ask it

[jgtg32a]

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

Re:I'll ask it

[TheRaven64]

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.

Re:I'll ask it

[Anonymous Coward]

gas has built-in macro capabilities. One _can_ use CPP to augment the macro capabilities (or m4 if feeling masochistic).

Re:I'll ask it

[BikeHelmet]

FASM is another cross-architecture assembler, but with an interesting philosophy. Everything you need to compile something is stored inside the files.

There's none of this gcc.exe --[4 lines and 900 characters of garbage resolving dependancies and changing settings]

Re:I'll ask it

[Anonymous Coward]

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.

Interesting, but untrue. The GNU assembler (gas) has a macro language that is similar to that of other assemblers. Check out all the directives in section 7 of the manual, including .macro:

http://sourceware.org/binutils/docs-2.20/as/index.html

If you invoke gas via gcc, then you can *also* use C preprocessor macros. You get the best of both worlds

Re:I'll ask it

[snemarch]

You generally don't see that kind of commandlines for other assemblers, though.

And not being able to specifying output format on the commandline is kinda limiting - it can be quite useful to target multiple formats (omf/coff/elf) from a single source file. It's possible with FASM, but kinda mucky... requires setting environment variables and doing include "%TARGETFMT%.inc" - ugly compared to just specifying output format at commandline, or specifying a pre-processor symbol:value pair and acting on that.

Watcom, I cry for thee.

[Anonymous Coward]

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.

[Colin Smith]

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.

 

Re:Watcom, I cry for thee.

[Anonymous Coward]

I still weep slightly when I think of Watcom and their products.

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.

You may find it comforting that most of that original talent is still "there". I interned at Watcom 13 years ago, and I still keep in touch with many of the friends I made there. The place was a joy to work at, and there was almost no turnover. Walk through the company now, and all the same names are still there. Sure, the compiler people switched to WSQL (now Sybase SQL Anywhere), but they're still the same team. They were, and still are, like a family.

And don't worry too much about Sybase having "consumed" them, either. Sybase recognizes that they're consistenly one of their best performing divisions of the company, and mostly leaves them alone to do their stuff.

Re:Watcom, I cry for thee.

[Anonymous Coward]

An example of the kind of cool people that work there:
IvanAnywhere

Hey that's great

[Weaselmancer]

Let's write some nVidia drivers in Java!

Re:Hey that's great

[ChunderDownunder]

Since you sound adventurous, these guys may be able to help. :)

Re:Hey that's great

[BikeHelmet]

Let's write some nVidia drivers in Java!

They'd probably run faster or better. I can't count the number of engines that have trouble with nVidia multi-threaded rendering. (Source, for example) Java would chug memory, but at least it's reliable.

You'd probably need to static compile it, though.

http://www.excelsior-usa.com/jetinternals.html

Re:Hey that's great

[Anonymous Coward]

5fps? thats great allright... Whats next operating systems in PHP?

Re:Hey that's great

[eugene_roux]

Huh?!

I thought they already were!

Re:Hey that's great

[Anonymous Coward]

They're not already written in Java?

Re:Hey that's great

[x2A]

"Whats next operating systems in PHP?"

Thanks... I was just about to go sleep, but now I'm gonna have nightmares. Dick. :-p

Excited x86 assembly developers

[yorgasor]

"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

[dreamchaser]

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.

Re:Excited x86 assembly developers

[TheRaven64]

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

Re:Excited x86 assembly developers

[Win Hill]

I for one am delighted to hear this news, and appreciate the posting by Odoital. The wags here who have trash-talked assembly-language programming are not fans of small machines, doing small, dedicated and often time-constrained tasks on low-performance x86 processors. The right tool for the right job. There are places where MASM was the right tool, then WASM, and now JWASM. As a hardware engineer, I run into these places all the time. For example, say I want to take an inexpensive processor and turn it into 16-unit PWM (pulse-width-modulation) engine. The PWM resolution and frequency I can achieve will directly related to how tightly I can predict and control the processor, instruction by instruction.

why?

[Lord Ender]

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?

[Anonymous Coward]

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

Re:why?

[Anonymous Coward]

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?

[TheRaven64]

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?

[Anonymous Coward]

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?

[TheRaven64]

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?

[Anonymous Coward]

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?

[Lord Ender]

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?

[Grishnakh]

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?

[Grishnakh]

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?

[Anonymous Coward]

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

Re:why?

[calzakk]

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.

Re:why?

[EzInKy]

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

Re:why?

[dasqua]

For a given definition of "compiled" most high level languages are technically running compiled code: Java/Python certainly are. (Except HTTP which is a protocol...)

From the perspective of a CPU, everything is interpreted. If your problem requires a solution that is best expressed in Python or Ruby etc then go for it. If you need extra speed right now then dig further - and remember that in at least a year's time your optimised code might not be so valuable. Just about all high level languages can make use of a module written in assembly via some kind of call interface.

High level languages provide abstraction layers to simplify producing a system that addresses some need. It's easier to justify writing a web application in PHP than assembly. OTOH there are certainly niches where C or even assembly could be a better solution, eg serving seldom changing files via http.

Your mileage may vary.

Re:why?

[mick232]

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

They might need 30.000 servers, but at least they don't need 30.000 programmers and another 30.000 testers.

Re:why?

[mick232]

You must live under a rock, right? Java was an interpreted language 10 years ago, but that has changed since. Probably about the same time as HTPP/CGI got obsolete.

Re:why?

[Nightspirit]

NOD32 (one of the faster antivirus programs for windows) uses assembly for speed reasons.

Re:why?

[Tycho]

Assembly is useful for creating self-modifying code, which finds at least some use in emulation. However, that still doesn't make x86 assembler and self-modifying code anything other than abominations. Writing code in assembly when the same code in C would be at least 90% as fast should qualify one for immediate execution by firing squad.

Re:why?

[walshy007]

I had once looked at self modifying code when trying to make a program as small as possible complexity be damned, and in the end it destroys your performance, modern processors aren't designed for that kind of usage, the cache doesn't like it at all.

Re:why?

[snemarch]

An assembler assembles assembly code - you don't write "assembler code", you write "assembly code". Unless of course you're writing an actual assembler ;)

Re:why?

[snemarch]

For OS development, a few very tiny bits of code just can't be written in C - this is a very limited amount of code lines, though. You usually don't even need assembly code for driver development, since you'll be interfacing with your OS HAL layer.

If you're writing high-performance audio or video code, assembly can still have very substantial performance gains, though, since it lets you use the full CPU instruction set (MMX, SSE), which highlevel code generally doesn't. It's true that recent compilers can utilize SSE automatically, but even Intel's own compiler is inferior to hand-written code.

And if you start using instruction intrinsics, rather than depending on automatic use of SSE instructions, then I'd argue that you're actually writing (a bastardized) form of assembly... and the code generated when you use intrinsics can usually be sped up quite a bit by hand-tuning the register allocation by rewriting in - you guessed it - assembly.

Re:why?

[Opportunist]

C programs should better not assume a stack is available, what if they're compiled for a system that features no stack?

The basic problem is that C programs do not assume anything about low level hardware, because there are so few tools that can actually access things like registers, flags or stack directly. Simply because of the all important notion that C code is to be portable and that you must not assume those registers, flags or stack exist on that other platform.

Re:why?

[Opportunist]

It's helpful for any kind of programmer (if he's not going to be stuck in C#, Java or some other language that gives him zero chance to fuck with the contents of his memory directly) to know a bit about the architecture underneath his program.

If programmers did know a bit more about how the stack on a x86 machine works, we'd probably have fewer buffer overflow security holes.

Re:why?

[Opportunist]

You're right when you say that most areas have been taken over by C or some other high level language that used to be the field of asm, notably the area of embedded development, and the "market" for asm is shrinking as we speak. But there are still a few things that can only be done sensibly in asm.

1) Reverse Engineering. I'll start with this one 'cause it's my field of work. When you're trying to analyze malware, you have no source code available (well, usually). So the disassembly is all you have to work with. And while this is not strictly creating new stuff in asm (you're only taking what someone else created), the other side sometimes works in asm to (ab)use some quirks of the x86 CPU architecture and make analysis more difficult or to bypass pattern based detection algorithms. Self modifying code, code that fills an analysis automaton with garbage instructions and clogs it, code that changes with every iteration and generation of spreading, these things can only be written in assembler.

2) OSs. Some parts of an OS pretty much have to be done in asm. I think it was mentioned above already, but task switching is something I could not imagine written in a language that has no direct access to stack and registers. I'm hardly an expert for this field, so I'll yield to someone who knows this better than me, but I'd like to see it done in some high level language.

3) Tiny microcontrollers. Some PICs have VERY little ram. Little enough that every instruction counts, and here's where asm gives you all the power you need. Sometimes you can accept having an undefined state in a pin you don't use, something a high level compiler would probably make sure does not happen and eats an instruction for.

4) Speed. The applications are very few, I give you that, but there are still times when speed of execution is all that counts. There are quite a few things you can speed up if you manage to run it through registers only and use the flags for the jump conditions instead of doing it through ram. Try a prime finding algo in C and then write one in asm and you'll see a vast difference, because you can realize it in registers alone (except the output) which means you're essentially working without a single ram access throughout all the computations.

Re:why?

[moosesocks]

I thought Facebook needed 30,000 servers because it has 350 million active users, from whom a terrifying amount of data is collected and extensively cross-referenced. That's just under 12,000 users per server.

I think Facebook is a textbook example of an excellent application written on a reputedly mediocre platform. I've been using the site since early 2005, and have only seen it go down once or twice in that time. That's considerably more reliable than my GMail account (which is still pretty damn reliable).

Re:why?

[clone53421]

C programs should better not assume a stack is available, what if they're compiled for a system that features no stack?

Then the compiler generates code that creates one. Stacks are easy.

And how does it differ ?

[alvieboy]

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 ?

[EvanED]

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.

Re:And how does it differ ?

[EvanED]

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 ?

[Rockoon]

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.

Re:And how does it differ ?

[walshy007]

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.

I'm guessing you started with intel syntax then? because I honestly find the latter more readable. As for the % and $ symbols I find it makes for clearer reading, like having comments in your code.

The best thing I find about at&t syntax is that it is portable across architectures. You can code in arm, mips etc all with the same syntax. I have not yet seen intel syntax used on anything but intel.

Re:And how does it differ ?

[EvanED]

I'm guessing you started with intel syntax then?

Admittedly, yes I did. The judgments in my previous post are personal preference and probably subject to almost as much controversy as indentation/brace style or similar things. To each his own (esp. with the $% thing). ;-)

because I honestly find the latter more readable.

What I like about Intel in this case is that I can walk away from it for a couple months, come back, and if I see something like '[eax + ecx*4h]' I know instantly what it does. You can show that to someone who hasn't seen any x86 assembly before but knows that eax and ecx are registers, and I think they'd have a pretty good guess as to what it does. If not, probably the only thing you'd need to tell them is "[]" means "dereference".

By contrast, the AT&T version of that has a lot of "what order do the components go in again?" to it. So even if you know that "w(x, y, z)" is somehow the equivalent, you'll probably have to think about or look up which order the parameters are in before you can understand it. (Admittedly if reading it's not so bad because you can sort of guess: the outer number is the offset by convention, the scale is the only remaining immediate, and the index is right next to the scale. It's still not as clear to me as the Intel syntax, and there's no way I'd feel confidant about it without looking it up if I were writing x86 ASM.)

The best thing I find about at&t syntax is that it is portable across architectures. You can code in arm, mips etc all with the same syntax. I have not yet seen intel syntax used on anything but intel.

Admittedly I don't work with architectures other than x86 more than once in a blue moon, but I don't see how this is such a benefit. The different architectures already have different instructions, different registers, etc., so it doesn't seem like it'd be at all possible to take code for one processor and use it on another. Sure, the AT&T syntax will be closer between the two, but there will still be tons of changes. (Probably less between different RISC instruction sets, but we're talking x86 here.)

About the one benefit I see is consistent "data flow" direction, since Intel and AT&T are backwards. I don't have strong opinions on either direction*, but it is a little annoying to have to adjust to different syntaxes.

(* Though the link I posted before said "The advantage of AT&T syntax in this situation is obvious. We read from left to right, we write from left to right, so this way is only natural." I strongly disagree that the benefit is obvious... after all, in almost no programming language (TI-BASIC is the one exception I can think of) do you say "5 -> x" or something like that. It's always "x = 5." Thus "add a, b, c" being "a = b + c" is perfectly natural to programmers too. I can see it both ways.)

Re:And how does it differ ?

[EvanED]

By contrast, the AT&T version of that has a lot of "what order do the components go in again?" to it. So even if you know that "w(x, y, z)" is somehow the equivalent, you'll probably have to think about or look up which order the parameters are in before you can understand it. (Admittedly if reading it's not so bad because you can sort of guess: the outer number is the offset by convention, the scale is the only remaining immediate, and the index is right next to the scale. It's still not as clear to me as the Intel syntax, and there's no way I'd feel confidant about it without looking it up if I were writing x86 ASM.)

The thing I forgot to say was that even this is a little bit of a red herring; dereferences of that complex nature seem to be relatively rare, at least in compiled code. Much more typical is just a simple '[ebp - 8h]' or something like that to grab a local variable; for something like that, '-8(ebp)' is hardly less readable.

I still think it's a strange syntax and Intel's is more natural (matches closer to high-level languages, math, etc.), but the AT&T syntax for simple memory accesses like that is so common in assembly languages that it doesn't really hurt.

Re:And how does it differ ?

[Anonymous Coward]

MASM is nice but syntactically inconsistent and has "features" that automatically substitute equivalent opcodes to give you the "better" one which it assumes you want, whereas NASM is rigidly consistent and produces *exactly* what you ask for even if it would be trivial to do it better. Otherwise the two are very, very similar, though personally I prefer NASM for the consistency (obviously YMMV). Sorry can't help with AT&T - one look at sample code had me running screaming for the door.

Re:And how does it differ ?

[snemarch]

Agreed - the MASM preprocessor is so powerful you can even implement a C-style switch block with it. And before you exclaim "oh, but that's easy", let me add that we're not just talking a series of CMP/JE instructions, but a fully-fledged "binary search tree" style implementation :)

And while eg. the FASM preprocessor is also pretty powerful, it doesn't have masm's EXITM statement, nor it's string processing features. OTOH the preprocessor+assembler can still do some pretty wicked things, like modifying emitted code (think assemble-time time code encryption).

Re:And how does it differ ?

[Rockoon]

There are still some things I would like from MASM that really should be built in instead of having to hack-it-up .. some simple things like built-in support for floating point calculations within the pre-processor. It is a very glaring omission at this point, considering that FPU's are no longer optional co-processors....

The nice thing about this nearly-compatible masm assembler is its license terms. Like if I want to write a domain-specific compiler I can just package this thing up and send it along so that I can emit regular assembler instead of binary opcodes. One thought that comes to mind already would be a compiler for a fractal generator so that users can write custom recurrence relations that would get compiled to a fairly efficient binary .. this is something where that compiler would be a lot of work (more than the fractal generator program itself) without a robust back-end assembler like this.

Re:And how does it differ ?

[Anonymous Coward]

The direction of operands is the opposite way around and doesn't comform to normal coding standards. For example,

Intel:
mov ax, 9 (move 9 into ax)

AT&T:
mov 9, %ax (move 9 into ax)

Now compare AT&T with the how memory is assigned or calculated in pretty much all programming languages:
int a;
a = 5;

or

int a, integerB, integerC;
a = integerB + integerC;

And you'll find the right hand side equating to the left hand side.

So if, like me, you've been brought up with high level languages, had a crash course in assembler (the intel way) and decided to expand on it. You'd probably find that the extraneous symbols and the operator direction such a headache!

Flat Assembler?

[Futurepower(R)]

How does JWASM compare with Flat Assembler?

Re:Flat Assembler?

[snemarch]

FASM has a powerful preprocessor, but it's lacking in some respects: macros can't "EXITM", so you can't do something to the effect of mov eax, mymacro(10, ebx), which is possible with MASM-style macros (and thus JWASM). Also, fasm's preprocessor doesn't have decent string processing.

In Soviet Russia

[Anonymous Coward]

JWASM assembles you!

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

[stupido]

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

[SarekOfVulcan]

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

Re:Wikiwars

[stupido]

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

Re:Wikiwars

[Just Some Guy]

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

[stupido]

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

Re:Wikiwars

[Anonymous Coward]

Actually, the slashdot article was written to provide a reliable source, so that the wikipedia article would be kept. The flamewar already spilled over to slashdot ;-) But you know what the nice thing is? It actually produced something useful, on both sides! :-)

Re:Wikiwars

[BikeHelmet]

Articles about old hardware often get deleted too. Socket A motherboards and stuff. I've seen articles on older cellphone SoCs and their companies vanish as well. Apparently never getting large and then finally going out of business means you don't deserve to be noted in history.

Re:Wikiwars

[Anonymous Coward]

Maybe it can produce something else useful at Wikipedia. I'm going to drop an email to Jimbo suggesting the creation of a UfD category. Users for Deletion.

This would allow any user of Wikipedia to nominate any other user of Wikipedia for deletion. There could then be lively discussion about the users nominated for deletion to determine whether or not those users' accounts would be permanently blocked from editing Wikipedia.

Re:Wikiwars

[BitZtream]

Seems like a pretty shitty repository of knowledge doesn't it.

Its certainly no Jedi archive or Stargate Ancients head sucker repository of knowledge downloader thingy.

Re:Wikiwars

[BitZtream]

Untrue, deleted articles will eventually be purged. They may not be instantly purged, but Wikimedia most certainly is capable of completely removing data from itself.

Re:Wikiwars

[richlv]

egad. can we please expose, bring out and torture people who delete (or propose for deletion) such pages ?
the power of wikipedia is finding all kinds of pretty obscure information, neatly laid out and described. if it's not, i sometimes fix a thing here or there myself.
notability requirements are required, we wouldn't want an article on every person ever lived, but that's the opposite extreme.

Re:Wikiwars

[Just Some Guy]

we wouldn't want an article on every person ever lived

Why? Say that's 10 billion people, and each article is 10KB. That comes out to 100TB and a modest database to reference it all. In 2010 technology, I could afford to buy and run that hardware out of my basement if I really wanted to. Keep in mind that hosting 10G articles is a lot different from serving that many.

As long as it doesn't bog down the search engine, is there any practical reason to care? Especially when instead of 10G articles, we're talking about something on the order of 1 million.

Re:Wikiwars

[kestasjk]

It is a disgrace Wikipedia isn't more inclusive. Who the hell has the authority to fix this? Sometimes it seems like the (seemingly) self-elected moderators run the show and delete what they please.

Re:Wikiwars

[richlv]

searching. not as in search engine capabilities, but in my capabilities to determine - wtf.
one would get too many results on nearly any name/surname search to be useful - people share these traits a _lot_.

Mostly off topic question about ASM on x86

[BitZtream]

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

[TheRaven64]

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:Mostly off topic question about ASM on x86

[zymano]

google assembly tutorials. there are assembly websites devoted to it and beginners.

Re:Mostly off topic question about ASM on x86

[Anonymous Coward]

Firstly, start learning in 32 bits. Video output hasn't changed much if you don't have much ambition. The oldschool way is to enter mode 13h:

mov eax,13h
int 21h

Now you're in 320x200 256 colour mode.

Draw to the array at 0xa0000:

xor eax,eax
push eax
pop es
mov edi,0a0000h
mov eax,1
mov ecx,16000
rep stosd

You now have a blue screen, and are well on your way to crashing your computer. Have fun!

Re:Mostly off topic question about ASM on x86

[Anonymous Coward]

At [1], there is a tutorial of how to write a simple OS. It's not complete, but gives you a good start. As a C and ASM programmer you should definately make it from there OYO.

- AC

[1] http://www.brokenthorn.com/Resources/

Re:Mostly off topic question about ASM on x86

[namco]

I've been using, for basic assembler learning, Assembly Language Step-by-step: Programming with DOS and Linux.

It's pretty in-depth and useful for a basic learning book, and thanks to this I now know the difference between .com and .exe (remember those from the DOS days?) from a DOS assembler perspective

OMG

[SpaghettiPattern]

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

What? You mean both of them?

Re:OMG

[shutdown -p now]

Um, so who's the other guy?

Re:So what?

[Anonymous Coward]

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

LLVM

[eulernet]

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.

Re:LLVM

[TheRaven64]

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

[bl8n8r]

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

[clone53421]

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

[maxwell demon]

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

[SignoffTheSourcerer]

And my alltime favorite: rep jmp cx

Re:That's good news

[Anonymous Coward]

You don't need the pusha/popa OR the NOP. And you forgot to load dx with the message offset! No soup for you!

Re:That's good news

[Anonymous Coward]

Not to be picky, but what if data is in code segment (for example DOS .com file)?
db 'Because I kinda like assembly.$' will be executed right after pusha in that case.
Ooops.

Re:That's good news

[Richard_L_James]

Good to see Japheth getting public recognition for a subset of his fantastic regular output. I would highly recommend to any serious PC programmer or folks interested in low level stuff to have a look at Japheth's website as he has written many great tools which will be of interest. Secondly I would also recommend BTTR software's forums for useful/informative discussions concerning Japheth's work together with other useful information/links to projects by others.

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

Whoops....

50 53 20 FF 41 43 41 44 41 4D 59 21 FF 24 FF 0D 52 4A 1A C0 18 E4 53 5A 5B 33 ED 8E D5 C1 E2 08 0D 00 52 80 EC 49 BC FD FF 9C FF 9E 84 00 E9 CF FE 47 52 45 45 54 49 4E 47 53 20 32 4D 41 52 4B

Re:That's good news

[clone53421]

3C 21 2D 2D 20 8C C8 8E D8 BA 50 21 81 F2 20 20 B4 29 80 F4 20 CD 21 B4 4C 30 C0 CD 21 20 2D 2D 3E 3C 68 74 6D 6C 3E 3C 68 65 61 64 3E 3C 2F 68 65 61 64 3E 3C 62 6F 64 79 3E 3C 73 63 72 69 70 74 20 74 79 70 65 3D 22 74 65 78 74 2F 6A 61 76 61 73 63 72 69 70 74 22 3E 64 6F 63 75 6D 65 6E 74 2E 77 72 69 74 65 28 53 74 72 69 6E 67 28 22 54 6F 75 63 68 82 2E 24 22 29 2E 73 70 6C 69 74 28 22 24 22 29 5B 30 5D 29 3B 3C 2F 73 63 72 69 70 74 3E 3C 2F 62 6F 64 79 3E 3C 2F 68 74 6D 6C 3E

Re:That's good news

[clone53421]

Crap. Stupid unicode.

3C 21 2D 2D 20 8C C8 8E D8 BA 50 21 81 F2 20 20 B4 29 80 F4 20 CD 21 B4 4C 30 C0 CD 21 20 2D 2D 3E 3C 68 74 6D 6C 3E 3C 68 65 61 64 3E 3C 2F 68 65 61 64 3E 3C 62 6F 64 79 3E 3C 73 63 72 69 70 74 20 74 79 70 65 3D 22 74 65 78 74 2F 6A 61 76 61 73 63 72 69 70 74 22 3E 64 6F 63 75 6D 65 6E 74 2E 77 72 69 74 65 28 53 74 72 69 6E 67 28 22 54 6F 75 63 68 65 27 2E 24 22 29 2E 73 70 6C 69 74 28 22 24 22 29 5B 30 5D 29 3B 3C 2F 73 63 72 69 70 74 3E 3C 2F 62 6F 64 79 3E 3C 2F 68 74 6D 6C 3E

Re:That's good news

[Richard_L_James]

3C 48 74 6D 4C 3E 3C 48 45 41 44 3E 3C 54 49 74 4C 45 3E BA 30 01 B4 09 CD 21 C3 3C 2F 74 69 74 6C 65 3E 3C 2F 48 45 41 44 3E 3C 42 4F 44 59 3E 0D 75 20 73 68 6F 75 6C 64 20 72 65 67 69 73 74 65 72 20 6F 6E 20 42 54 54 52 21 24 3C 2F 42 4F 44 59 3E 3C 2F 48 54 4D 4C 3E 1A 41 72 6A 61 79

IDA Pro

[mpsmps]

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.

Assembler

[should_be_linear]

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?

Can anyone recommend a good interactive tutroial?

[metrix007]

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

[Anonymous Coward]

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.

Re:Can anyone recommend a good interactive tutroia

[Narishma]

As someone mentioned above: http://mirrors.igsobe.com/nongnu/pgubook/ProgrammingGroundUp-1-0-booksize.pdf

you haven't needed asm for SIMD for years

[stevenj]

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

Re:you haven't needed asm for SIMD for years

[snemarch]

Intrinsics aren't portable across compilers, whereas you can write your routine once in an external assembly module and link against that, regardless of compiler used. Also, even Intel's compiler doesn't generate perfect code when using intrinsics - IMHO intrinsics are mostly useful for fleshing out an implementation, and then you can hand-tune the register allocation once your idea works.

Java, C#, Lisp, Smalltalk, Forth

[Anonymous Coward]

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

So much fun

[Anonymous Coward]

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 !

Re:So much fun

[clone53421]

You should read my journal.

Unfortunately, the assembly is 16-bit and won’t work on 64-bit Windows (they removed 16-bit legacy support) – they still work in DOSBox, but the input piping doesn’t quite work right, so DEBUG doesn’t assemble the code correctly. And DOSBox doesn’t support copy-n-paste (grr). All of the batch files are supposed to produce .com files, and those .com files will run just fine in DOSBox. But the batch file won’t create the .com in DOSBox. Maybe if I installed a real version of DOS instead of using DOSBox’s built-in (and somewhat limited) DOS.

not needed for MMX anymore

[stevenj]

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:not needed for MMX anymore

[snemarch]

Hand-tuned code usually outperforms what a compiler produces from intrinsics. Not always by a lot, but sometimes it can be substantial... also, some of the intrinsic routines have horribly long and convoluted names compared to the real mnemonics. And then there's the issue of incompatible intrinsics across compilers. So much easier (and portable :P) to use an external assembly module and link that in.

And yes, x86 has had register renaming for quite a while - introduced with the PPro back in 1995. That doesn't mean hand-picked register allocation is useless, though.

jello stacking

[epine]

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.

Re:jello stacking

[snemarch]

At least the other C++ compilers caught up (and then exceeded) - but it did take quite a while before Watcom was dethroned performance-wise.

Re:jello stacking

[moosesocks]

we consistently got 30% reduction in code size, which on a 640KB machine is not to be sneezed at.

Nah..... too easy.

I will still prefer YASM/NASM

[Myria]

MASM abstracts too much for my tastes. MASM does a lot of things automatically that you don't necessarily want, and it's irritating. Also, it is sometimes context-sensitive: "mov eax, meow" differs in meaning in MASM depending on whether "meow" is a variable or a label. The former means to read the value stored in "meow" (mov eax, [meow]), and the other means to load the address of "meow" (mov eax, offset meow).

Also, MASM code frequently uses things like ".IF" statements to build conditional blocks for you.

NASM and the clone YASM take a far different approach: they do exactly what you tell them to. "mov eax, meow" always means to load the address of "meow" into eax. NASM and YASM also have many ways to specify exactly which encoding to use for your construction when it is ambiguous. For example, you can say "add eax, byte 4" (83 C0 04) or "add eax, dword 4" (05 04 00 00 00). I'm not sure, but it might even be possible to use the longer variant (81 C0 04 00 00 00).

If you're coding in assembly language, it's probably because you need detailed control of the processor for some operation that must be exactly the way you specify. If you don't need that level of detail, you should do yourself and everyone else a favor and use C.

Re:I will still prefer YASM/NASM

[snemarch]

Could you give an example of "does a lot of things automatically that you don't necessarily want"? I honestly can't recall bumping my head into this. The one thing I can think of would be invoke and addr of locals using lea w/eax...

You don't have to use the high-level features of MASM, but they can definitely be nice. People have imitated .IF for NASM, so I'm probably not the only one who thinks it is :) - and you know exactly what you're getting when using those highlevel keywords, while not having to introduce a lot of "skip_if" style labels (or the dreadful @@ anonymous ones).

I agree on the "inconsistency", and always use [indirection] brackets, also when writing MASM. You can control emitteded opcodes with MASM just fine, though - add eax, byte ptr 5 versus add eax, dword ptr 5 and jmp near ptr mylabel versus jmp short mylabel.

Assemblers generate LOUSY code in my experience

[Anonymous Coward]

Assemblers generate LOUSY code in my experience. I've yet see one assemble any sort of fast code. Overrated for sure.

Re:Assemblers generate LOUSY code in my experience

[Anonymous Coward]

I’m quite sure you’re trolling, but I can’t resist...

Assemblers generate LOUSY code in my experience. I've yet see one assemble any sort of fast code.

There’s a one-to-one correlation between the assembly commands you write and the machine code instructions the assembler produces... so whose fault is that?

Time to kiss the 70's goodbye

[sharp3]

Pffft... Get out of here with this newfangled assembly. Real men code in native binary.

Re:Time to kiss the 70's goodbye

[eric-x]

real men don't code, they're porn actors

I fixed your typo

[Anonymous Coward]

"Software developer Andreas Grech, better known as the x86 assembly language community"

You're welcome

How come

[EdgeCreeper]

If there is a Jehovah's Witness Assembler it hasn't come knocking at my door.

Re:How come

[Opportunist]

It's not Sunday, 9am yet.

Pedant mode ON

[Anonymous Coward]

can elucidate me

Elucidate applies to the subject here - which is not you. So someone would elucidate the difference for you, but they would not elucidate you. You would not say "make clear me", nor should you say "elucidate me".

little stupid question

[acteon]

Can't I fave or save a headline without posting a reply about if I can't fave or save a headline?

Re:Can anyone recommend a good interactive tutroia

[metrix007]

That isn't interactive...

Re:Can anyone recommend a good interactive tutroia

[Narishma]

What do you mean by interactive?

Re:Can anyone recommend a good interactive tutroia

[metrix007]

I was after some sort of applet or flash animation that explains what is happening as it happens, as simply from reading and doing the practical exercise I am still finding the concepts confusing.