Assembly coding

[f0dder]

rjbull, Assembly coding doesn't really have anything to do with genius - just a lot of stubbornness. Like cutting down a tree with a kitchen knife.

[Carol Haynes]

Assembly language is very useful if you want to write really efficient, fast compact code. It is a lot faster to execute than any compiled language. Trouble is most of the libraries available are written in compiled languages these days!

[Edvard]

Like cutting down a tree with a kitchen knife.

No, more like growing the tree to withing 1/16 of optimal diameter (measured weekly), mining the ore to smelt to iron, carving a mold for a wide-blade axe head, melting the iron in a coal-fired blast furnace (coal pilfered from train wreck site in desert), pouring the mold, sharpening the axe with medium grit to a knife-edge and heating to proper temper, quenching in oil (of course), sharpening again with extra-fine to a razor-edge, taking the axe to the tree and stripping off one branch about 2" diameter, tamping the axe head onto the branch, taking a modest swing and...

chopping the sucker off at ground level with one whack.

That's assembly programming. You're right. It doesn't take genius. Just a bull-headed unwillingness to settle for a $12.99 fiberglass-handle job from Wal-Mart...

There's a hacking pun in here somewhere, I just know it...

[brotherS]

[f0dder]

I've done assembly programming since... early/mid nineties, so I know the drill. Saying that it's faster than any compiled language is nonsense, that depends on the skill of the programmer. And the kind of naïve code written by people who do full-application asm programming tends to be worse than what today's C/C++ compilers can produce. Sad but true.

It used to matter a lot in the old days when compilers were lame and computers were slow, some of my Pascal applications from back then approach 50% assembly code. Today, it's mostly a waste of time, except for a few special areas where you can get some nifty speed improvements.

The people to blame are incompetent programmers, Borland's lousy compilers, programmers linking statically to MFC and VCL instead of dynamically, time-to-market, outsourcing, and lousy/incompetent component programmers (I'm sure Mouser will agree on this one).

Edvard, cute analogy - but looking at the so-called quality of the average assembly coder... I'd almost prefer Delphi code generation (and THAT is sloppy).

[Edvard]

Agree to the delphi code... ick. Also agree that it is the programmer themself who determines the quality of the final product. As I mentioned before, I used to program the daylights out of Apple ][e's back in the day. I wrote some AWFUL-looking apps that worked pretty well, (a word processor that was about half the size and speed of the one our computer teacher made us use...) and some very clean coded (after the computer programming teacher got after me) things that either didn't work or were useless. I noticed my programs got a lot cleaner after I figured out the "gosub" command
Glad you like the analogy. As for the ability of such individuals to also clean up the sawdust, slag and coal ash, well, you know...

[mouser]

assembly coders are a special breed.  it really does require an intricate mind to be good at it; like most programmers of my age i did my share back in the old days.  hard for new programmers to believe but there was a time not all that long ago where computer programming sections of bookstores were FILLED with assembler books for different architectures, 8080, 8088, z80, 68000, etc.

however i have long consider myself in the camp that thinks programming code should promote reuse, readability, modularity, etc.  and from that standpoint assembly should be made illegal

[kfitting]

Don't forget that, as mouser mentioned, the area where assembly really shines is DSP.  I've done a little bit back in college, but my dad is currently using assembly in his projects at work: audio DSP.  For routines that need to run as close as possible to real-time, you can't beat the flexibility of Assembly!  Like anything else from C++ to VBA to AutoIt to .net, it depends on what you're trying to do!

For a fairly slick example of someone who does their coding in assembly and seems pretty darn good at it, check out www.grc.com


Kevin

[Carol Haynes]

I've done assembly programming since... early/mid nineties, so I know the drill. Saying that it's faster than any compiled language is nonsense, that depends on the skill of the programmer. And the kind of naïve code written by people who do full-application asm programming tends to be worse than what today's C/C++ compilers can produce. Sad but true.

It is unfair to say that sloppy asm code is no faster than compiled code. You can only compare code written by people of similar standard in their chosen skills - equally sloppy high level code (and there is plenty of that about) will be far slower than ASM code of a similar standard.

Well crafted ASM code will always beat well crafed high level code for time critical functions.

No one in their right mind writes ASM code for full applications any more, and in Windows it would be totally pointless as the Windows library code that it would have to reference almost constantly to make it compatible is written in probably some of the sloppiest and heavily (and badly) patched code ever written on the planet. There probably isn't a single kilobyte of windows code that hasn't had many multiple patches applied over the last 20 years (fixing bugs, shoring up failing security, maintaining backward compatibility with MSDOS 1, in many cases).

ASM still has it's place though in time critical routines for realtime applications.

Actually RISC based machines made ASM quite easy to write very efficient code with a fairly low learning curve.

I have a nostalia for ASM code of yesteryear as I taught assembly language coding for many years in 8 bit and 16 bit environments (but I have no desire to write any more - just a contented feeling to have been there and done that).

I do have colleagues who remember using binary code to bootstrap early computers (rows of switches to enter the startup sequence). God help you if the machine crashed

Anyone out there remember OCCAM ?

[mouser]

and let's not forget that asm skills come in very handy when debugging code produced by high level compilers, finding bottlenecks, optimization,etc.

both db and jibz here have found bugs in microsoft compilers by analyzing assembly produced.

[f0dder]

kfitting, http://www.grcsucks.com/ :^) - seriously, that guy is SO full of himself.

Carol, most of the windows problems are at the usermode level: IE, the shell, etc. There's simply too many people touching that code, and too many people who aren't good at it. On the other side is the NT kernel, which is a pretty nice piece of work (and yeah, there's even a few pieces of assembly in there - not much, though).

It is unfair to say that sloppy asm code is no faster than compiled code.

Yes and no - although this ends up being more of a time issue. Algorithm design in assembly tends to be a lot more time-consuming than in, say, C++ because of annoying things like the very limited amount of registers on the x86. Register allocation and function inlining are two reasons why an intermediary C++ programmer will probably end up producing better code than an intermediary assembly programmer.

The point is that it requires a lot more to produce good assembly code than it does to produce good C/C++ code. If you take a look at the various assembly-related resource around the net, you'll see people that DON'T go this extra way, end up producing code that is worse than a compiler... and, the worst part, many of them have this "omfg I am teh 31337 coz I code in ASM!" attitude.

And then there's this silly fascination and "it requires a genious to program in assembly" - well, it doesn't. Not even to write decent code.

But I fully agree that assembly skills are useful, and there's still a lot of places where assembly makes sense. And I'm glad I still have a PII-MMX-350 for testing, so I don't become a sloppy programmer

[kfitting]

Heh heh, interesting site f0dder.  I hadn't heard any good debunking about grc (granted I hadn't looked!) and there are some interesting things pointed out.  Thanks! 

One thing, however, I have downloaded a few of his programs (not any of the "serious" ones, mind... there is one that assembles a jigsaw puzzle, and his old optout) and have always been impressed by how much they do in such a little file size.  Now, maybe GRCSucks can debunk this too (I honestly haven't read more than a few articles), but in a time when everything seems to be at least a meg in size even if it merely changes a pixel on your screen, seeing an app come in at less then 40k with a full GUI is pretty neat!  Just imagine if windows programmers would do that today... harddrive manufacturer's would be out of business!!

So, thanks for the info, I will continue perusing.  But I still think a few of his apps are mildly impressive... granted,  perhaps not worth big, BOLD, and colorful fonts... but still impressive! 

Incidentally, one of the biggest things I remember about programming assembly is that I made it through the labs because of one of my partners.  Not that I sat back and let him do all the work, I was good at structuring the program... but he had this inane gift of being able to look at an output and realize that we wanted to see and FE instead of an 9A because our result should be negative...  I still don't understand how he did that!

Kevin

[f0dder]

Remember that he (iirc) uses executable compression - that does help bring size down. And what he does in "such little space" isn't all that impressive... it's pretty easy making tiny executables in in HLLs. One of my tools (binary file -> coff object file) is 4k uncompressed, yet it's coded in C++, with the use of a minimal and very granular runtime library, like Jibz' WCRT. If I banged the API directly, I might be able to get it down to 2kb, still with C++ code (objects and everything).

But it's true that most people don't take the time to program in this way - it IS convenient to slap together some components. I tend to strive for some middle ground, though - I don't think some hundred kb is bad for a functional app, and while I perhaps could get it down to 30-50kb, I prefer stability, ease of maintaining etc. to zealot strife for tiny executables.

The thing I dislike most about Gibson is his self-promotion, BIG BOLD LETTERS, fuzz-words etc. Especially on the SpinRite pages - the app might work, but there's way too many fuzzwords and too little information, the TechTV clips look like tele-evangelism, and... argh

but he had this inane gift of being able to look at an output and realize that we wanted to see and FE instead of an 9A because our result should be negative...

Actual numbers? 2's complement isn't that bad to work with; a byte >= 80 hex is negative, 00-79 are positive.

[kfitting]

Actual numbers? 2's complement isn't that bad to work with; a byte >= 80 hex is negative, 00-79 are positive.

No, not actual numbers... you don't expect me to remember something from my junior year of college 2 years after I graduated did you??!

Well, the day I remember most clearly when he did this type of thing was the day we had to make a square root algorithm.  I understood how to do it with the flow-chart, but while trying to keep all the logic and numbers straight while going through the assembly I just got turned around... we all hit our wall at some time or another!  He just hit his after me in this case and impressed me greatly!  It probably wasn't hard... but when you are sitting in an engineering lab for five hours trying to figure out why you are one bit off the answer, tired as anything, and confused beyond all reasoning, having your lab partner look up from some furious scribbling and say, "we should be seeing this... here's where we're going wrong," is awsome!  But, he definitely was good with the nuts and bolts of assembly, something I just couldn't quite get my head wrapped around.  I got a good grade in the class, but the labs would have taken me 3-4x as long without him.

Yes, we all have our abilities... it remains up to us to be content with what and where we are!

Kevin

PS - while I admit to somewhat swallowing the hype of GRC, I must agree with you about all those big fancy fonts... something that always kind of annoyed me.  Sort of like those people who use a black starry background with small yellow letters - a different extreme but just as annoying!

[Mark0]

Anyone out there remember OCCAM ?

Present! The language for writing parallel code for the Inmos Transputer, right?
That remind me of a oh-so-cool! networking system for the Amiga, made trough the hispeed serial links of a Transputer: AdPNetwork, IIRC.

Bye!

[f0dder]

There's Occam as well - the guy with the razor. And the OCaml programming language