Ah, the good old days! When men were men, women were women, and we wrote code by carving it into the silicon wafers with a hammer and chisel.

I can't recall ever having written an entire program in assembly language. I might have done a small one, just for fun, on a TRS-80 in Z80 assembler back about 1979 or so.

However, back in the mid-1980s, a lot of C compilers were terrible at code optimization. They made up for it by letting you embed assembly language in the middle of C. So a lot of times, I would find some nested loop that was chewing up a lot of time, and accelerate the middle by recoding the C into assembly.

Also in the same era, as you mention, you could sometimes get to special features on computers with assembly language that weren't available from C.

For instance, I was on a team that got tipped off that the Mac II was coming out with a floating point unit on a chip. None of the existing Mac compilers or assemblers could use it, but I was able to hand-code some machine language instructions for it, and wrap those in 68000 assembly, and wrap those in C. I believe that was the first shipping, commercial Mac program that could use the FPU directly. It wound up being about 100x as fast as not having an FPU, and several times faster than using Apple's software wrappers for the FPU.

Later on, I worked on Mac AutoCAD when there was such a thing. The first revision had a bug, and they didn't want to replace the whole program. So I wrote a patcher that fit on a single floppy. It ran through the code and patched the buggy stuff by replacing it with a jump to some non-buggy code which it tacked on. That all had to be done in 68K assembly.

Since then, most of my use of assembly has been just reading it in a debugger. I once reverse engineered the assembly for a DOS device driver, rewrote it in C, and ported it to the Mac.

Nowadays, CPUs have changed so much, it's very hard for a human to write assembly code as fast or small as a compiler can generate. When you combine things like RISC instruction sets, branch prediction, multiple levels of caching, and multi-stage pipelines with several operations running in sequential/parallel in the CPU at once, the most optimized code for a particular operation can be very unintuitive unless you're a real expert.

3 things:

1) A medical computer used in eye surgeries. If you ever had any kind of such procedures done, there's a 50/50 chance it was done using my machine. Written entirely in assembly.

2) Several different vending machines and coin changers.

3) The first version of my personal web site.

There are more.

In Assembler? Lessee.

• 1969-1970: IRIS: 8 User Disk-based Timesharing system with Kemeney&Kurtz-style BASIC on 16 bit Data General Novas
• 1972: SpaceWars, an Enterprise/Klingon shoot-em-up on an IMLAC electrostatic graphics terminal
• 1973: A one-pass assembler/linker for the Jupiter 16-bit virtual memory minicomputer. (The one-pass scheme because I'd used a 2 pass assembler on the Nova, and doing two passes with a paper tape reader is painfully slow! The Jupiter started with literally no software initially. Since I didn't have an assembler or linker initially, I wrote the linker and assembler source code first. The linker was designed to accept an ASCII/hexadecimal object file. I hand coded the linker from its assembly sources into its corresponding executable binary, ugh. Then I hand-converted the assembler's source code into linker code, and debugged, until the hand-linked assembler could assemble the assembler source code, and thus reproduce itself. At that point it was rather easy to assemble the linker assembly source code :-}
• 1974: Wirewrap layout system that converted physical chip socket package/pin layouts plus logical wiring information to drive 2 axis semiautomated wirewrapping machine (using above assembler :-)
• Mid 70s: SDOS, a family of operating systems (RTOS, single user, multi-user, distributed nodes) for Motorola 6800/6809 CPUs, including dozens of device drivers
• Late 70s: ChessD, a full chess program for 6809 CPUs complete with entire Chess Encyclopedia.
• Since 1995: PARLANSE parallel language runtime system on x86, providing highly-tuned routines for managing the interactions between fine-grain multi-core computations supported by the PARLANSE ^[1] language.

These were all a lotta fun, but a lotta hours, and a lot of crossed eyes.

The early stuff was done with Teletypes and paper tapes. Did you know there's a skill in rolling up very long paper tapes, very fast, by hand, using a pencil?

For most of them, the principal roadblock was that the platforms on which they ran didn't have any real development tools. I built a lot of debuggers (single-step/display instructions, display registers, show/update memory...) as a matter of survival.

For the x86/PARLANSE stuff, you could get MASM, but debugging multi-CPU codes wasn't really a standard debugger problem; you mostly had design the code extremely really carefully and figure out synchronization errors in your head.

While taking a class on Computer Graphics, me and my project partner decided it'd be really cool if we created something worth our time instead of specifying an eagle's model in VRML (need I say more?). So, during the following 6 days, we put all our energy into two things:

1. Making the meanest 3.5kg sandwich(-es) we'd ever eaten before.
2. Coding an engine and a demo of all the techniques we've been taught in the course in x86 assembly. In addition, we wanted to implement additional stuff into it to produce a demo that would make its VRML counterpart look like, well, VRML.

So we did. It seemed surprisingly easy because we'd worked together a lot, and by then we knew each other's quirks, but it really wasn't. When we were done, we decided it wasn't enough. We wanted more objects on the screen, faster frame rates, more realistic lights. So we dug out some pen and paper to put our equations to the test, architecture manuals, etc. and soon we started asking people questions like "How can we do division on x86 faster than div?" which, when directed to our fellow students in the lab, usually incurred hysterical laughs. :-) When we actually got an answer, we were ecstatic. Then we found out about SSE2. We split operations - SSE/FPU for real numbers, MMX for fixed point. Reorganized our data and vectorized our ray tracer. We benchmarked something like 5K rps, which let me tell you, was awesome (and would be even if that number was way lower).

At this point people would pass by behind us and they'd stop for a second, look at our screens and exclaim: "What the hell is that?". And we'd be like, "Oh, it's our project for CS358. blah blah" and we'd be proud as peacocks.

Nine days after we first talked about it, we walked in the amphitheater where CS358 lessons were held with a laptop and showed off our demo, the engine and the source code (it's still by far the most condensed piece of code I've ever written in any language). When we were done, there was a short round of applause, after which the professor exclaimed "Entertaining, sure, but what about your VRML project? You know I can't grade you on this".

The laptop broke down later that day, we kind of just lost interest and we only got something like an 9 in CS358 iirc. We learned a whole lot, though:

• CG algorithms. More than we would've learned in class, anyway.
• Real time rendering
• Linear interpolation, perspective corrected texturing and why John Carmack is a Genius
• Anti-aliasing (on objects and on lights)
• Data hierarchies
• Geometrical operations (and why computing an inverse square root in SSE is a bad idea)
• Optimizations for speed, instruction pipelines, and cache thrashing
• One can't code on an empty stomach.
• Ignore the jackasses. And last but not least,
• Use version control. And backups. (all our source code was lost in a "tragic" incident involving the NFS server of our lab..)

Many years ago, I wrote a word processor for low vision users that showed big letters on the screen. It was on the Apple ][, used the high-res graphics mode, had printer drivers for the myriad of different printers available at the time (so it could print in big letters, too), and was written in 100% 6502 assembly language.

After I migrated to the PC (80286 with MS-DOS 3.3), I discovered high-level languages.

I coded several intros/demo on Amiga (Motorola 68000).. with SEKA Assembler It was really great, because you programmed directly on Hardware ($DFF180 was color 0)..

We had a lot of fun with copperlists, blitter and counting rasterlines, to make sure, that your intro will not drop a frame

I have a 30 page listing of one of my first intro, but unfortunately I do not know how to migrate them from my AMIGA DISKs onto my PC..

On Amiga you had 200 rasterlines resolution and all of the customchips were synchronized with the electronbeam of your tv set. So if you Music-routine takes 20 rasterlines to make sound, you have only 180 rasterlines lift to update your screen. It was imperative to refresh the screen every 1/50 second..

I wrote what I'm pretty sure was the first GIF display program for the Commodore 64. I was involved in the CompuServe forum for GIF images and I wanted to see the samples, but no one had written a program to display them on the C64 yet. So I did. Much of it was written in Basic, but since C64 Basic didn't have stack operators and was really slow, I wrote large parts of the decoding algorithm in 6502 assembly. I was maybe 16 at the time, but I had cut my teeth on Z80 assembly when I was 12 on a ZX-81, so by the time I had my C64 assembly was no big deal for me.

My GIF display program had full support for the format, including animations, despite being very limited by the C64's color modes. I had to implement dithering from 16 colors in the C64's high-res mode to the 256 color palette most GIFs required. Fun times.

I once implemented a Life game ^[1] in PDP-11 assembly, as a part of our programming course at the University. Of course it was run on an emulator.

Neither powerful, nor useful, but certanily fun!

AudioWorks ^[1] (1994), for the Acorn Archimedes (still on sale after 15 years!)

I used C for the primary User Interface, but a large chunk of it was ARM assembler: all the audio sample processing, along with low level audio drivers for sampling from Lark and Eagle sound cards, and providing high quality playback.

Ah, the good old days.

In the late 1970's I wrote a one-pass 8080 macro assembler, initially written using a simpler non-macro 8080 assembler, for a now-long-defunct 8080-based terminal manufacturer in Silicon Valley. It used one pass because the terminals ran a homegrown floppy-based O/S and I/O wasn't particularly fast. Assembly began by loading macros that defined values for all symbols like opcodes and register names. Each line of input source code was treated as an expression that the assembler evaluated per the macro definitions to generate equivalent object code. By simply changing the macro definitions, the same assembler could assemble programs for devices other than the 8080. That was done at least once for a different CPU used by the Hardware Test department, but I forget what that device was (perhaps a disk controller?). Once debugged, the assembler was of course also able to assemble itself. Source code created with that assembler is still around on the Net, as can be seen here ^[1]. The assembler was also used to hand-code an 8080 version of Kernighan & Plauger's "Format" program from Software Tools ^[2], which was published in Dr. Dobb's Journal ^[3] issue 35 in 1979.

Best assembly program? It's a toss-up between two. They were for class projects and the assembly classes were the hardest classes in our CS engineering program. The first one was an asynchronous serial-transmitter and receiver that I wrote on the Motorola 6800.

The second one is a hair more awesome. My team-mate and I wrote a pre-emptive multitasking operating system for the Motorola 68k. Actually you know what... the more I think about it, this is probably the best assembly program I ever wrote. I can't count the number of 3 to 4 am coding sessions I pulled to get it working. What makes me happy about it was that it was good code and good documentation too too (that mattered because our professor graded us on efficiency [program size and running time] and on documentation).

I definitely learnt a lot from those two classes.

The best program I wrote entirely in assembly language would have been an unreleased game for the Sega Genesis ^[1] console system. This was my best program because it was done in a combination of 68000 assembly (best assembly ever!) and Z80 coding.

The best program that I published was a game I wrote for the Atari Lynx platform in 6502 assembly language. I wrote several, and at the time hadn't worked with linking so they were all within a single .asm source file. It was long. It was tedious (it was assembly, after all) and the only non-assembly code was some processing code I wrote to create (cook) assets - in C.

I've written a TSR (Terminate and Stay Resident) for DOS in the beginning of nineties that emulated Slovenian characters on standard 437 codepage (and a similar one for 852 codepage as well). Codepages were a mess at that time because there was no standard of having custom codepages in 256 table codepage.

It was kind of a DOS service that heavily abused interrupt 17 ^[1]. But it wasn't just an easy program that would detect particular characters and than send additional data when such character was found. No. The program had to detect ESC/P2 commands and ignore those. And those could be quite complicated.

The software was a great success. People were able to use it in DOS as well as in command window in Windows (print pooling had to be disabled and direct printing enabled). It was still used with Windows 95. You can actually still find and download it on the net ^[2].

Later double byte codepages started to be standardised and printers supported them. So no need for my emulator any more.

Fire up the Way-Back Machine!

On the Apple with the 6502, the coolest would be the program that drew Serpinski Gaskets in hi-res mode at something like a reasonable speed. The one that earned me the most money was the music-player which I sold to students in high school for a pittance so they could play music with their mandatory graphical holiday demos for the mandatory computer class.

On the PC, the best assembler program was certainly the most-of-a-forth-compiler that turned college assembler class into something else entirely when the professor finally figured out that all the code for the actual class projects was wrapped up in data declarations. An astrophysicist by trade and teaching assembler only as a favor to the department, he learned that semester that there is no essential difference between code and data.

Best assembly language program I've written? "Hello World".

I kinda gave up assembly as a lost cause fairly early on - C was much easier to work with.

Me and a friend of mine made a "Tron"-style 2-player game with a scoring-system that only used BIOS-interrupts and was small, compiled, only around 300 bytes. In other words, it could be written to the first sector of a floppy and with the correct flags (0x55 and 0xAA or something at position 511 and 512 if I remember correctly?) it could run on pretty much any (x86) computer with a floppy-reader. :o)

No Man's Land ^[1], a 2-player (only) top-down 2D action shooter on the good old Amiga. Written in 100% assembler, I think it measured at about ~5,000 lines which I of course thought was pretty huge back then. Emphasis on "back then", this was a while ago. :)

The best one I wrote was when I was still at school. It was very short - about 100 bytes, plus a look-up table (squeezed into the tape handling reserved buffer page, but there was no tape drive attacked so that was ok.)

What it did was intercept screen output (on the BBC Micro - OSWRCH vector) and route the output to another system call, interpreting the characters and sending the appropriate codes to a speech processor. This enabled a blind keyboard user to be able to hear what the screen output was producing.

The reason I liked it so much was that it was really quite tightly written, as it had to co-exist with other running programmes. It did have some performance impact (the speech processor was the cause of that) but it itself was incrdeibly performant.

Another one was the screen-swap system I wrote for my part of my A-level graphics system. The BBC Master had 'sideways RAM' which was essentially a different section of memory, mapped to the same addresses as part of main memory, but they could be swapped back and forwards (paged) very quickly. So I set it up aligned with screen memory and wrote to the hidden page while the visible page remained static. This primative z-buffering made for a much smoother screen refresh - which was important in the application, because it was for children with learning difficulties and screen flicker disturbed them. (It worked with a touch screen, since they couldn't associate keyboard and screen as part of the same system ....)

I was very fond of 6502 assembly.

The only time I've ever really written complete applications in assembly language was in college, just to learn how.

With languages like C and C++ available, where you can mix asm with higher level stuff, it usually doesn't make much sense to develop entirely in assembly unless you're going for some freakishly low memory footprint.

I have developed some blazing fast math libraries in asm for game engines, and a number of components for some anti-cheat game software. The biggest hurdle was the tediousness of it all, from the coding to debugging.

I coded quite some quantity of assembly language for 8-bit microprocessors and micro-controllers.

I started on these first boards, with only the microprocessor (6800 IIRC), some peripheral circuits, a handful of 8-segment LED display and an hexa keyboard...
We coded the assembly, generated the hex codes by hand (looking in a printed table) and computing the jump offsets by hand, then inputing all these codes on the hex keyboard... :-)
Of course, the fun, beside doing the assignment, was to do some extra work, like making the LEDs to light up in sequence... :-D
And of course, if you cut the power down, you loose the code (later I had a board able to save code on a cassette tape...).

Later, I owned an Apple //e, with a 6502 processor (like the Commodore 4016 I owned before). I wrote a little assembly routine to make a three-screen drawing (which I drew with a joystick!) to scroll smoothly. Hey, I even won the second price of a contest of the time with this code! (First price was a MSX computer, second one was a printer, I was SO happy to have the second price! :-D)

One of my most remarkable assembly language work was done on a micro-controller, which was... controlling the hardware of a radio-altimeter (stuff sending radar signal to ground and analyzing resulting time to go back to see how close the plan is from the ground; critical for landing). So my code was real-time, measuring electric signals, communicating with the airplane (showing some primitive alphanumeric menu) via Arinc, etc. It was also monitoring the two other, different CPUs, each computing the altitude with a different algorithm, one written in assembly language two, the other in C. If they found very different values, my CPU was holding data, declaring the device as faulty.
All this for Boeing and Airbus, following very strict procedures and documentation, using a cross-compiler (on Sun stations), etc.
I learned a lot in this project, very enjoyable, even if a bit obscure (in exposure). Hey, perhaps you flied on a plane using my software... :-D

It was long time ago and first and last complete project in assembler was two player tetris with cheatcode that only 1 knew. I think it was 15 years ago.

A "hello world" program that would avoid "scanners" built to find hello world programs.

I took a class in malicious code so one assignment was to write a hello world assembly program. The next was to write a scanner that would detect hello world programs regardless of how they tried to obfuscate or hide. The best scanner was the one that (correctly) found the most of the other students programs in the shortest time possible. The best program was the one that hid from the most scanners.

Great fun and a relatively harmless way to learn about what virus writers do to avoid scanners (and what scanning engines do to counteract that... ad infinitum).

I wrote FPU trap fixup code for the DEC Alpha for NetBSD. (None of the RISC processors directly implemented IEEE FP w/o a SW layer.)

I have only coded pseudo assembler for a special interpreter during the first semesters of my CS studies. :-)

(And I am glad that I had to do it never in a real project)

As I was a student in mathematics I wrote some programs in Fortran on Mainframe. After studding of assembly language (just for fun) I rewrote one Fortran program in assembly. I spend a lot of time to do this. My program in assembly run much quickly (about 5 times) as the old Fortran program. All my college was thrilled. Some more time ago I studied operation system (also just for fun) and other possibilities which exists on the Mainframe and find out (also myself) that there are also another optimized Fortran compiler on the Mainframe. My assembly program was only 5% more quick as the old Fortran program compiled with the optimized compiler. After this experience I used assembly only as inline instruction in my C code or wrote only small functions in assembly which I used from another languages. The assembly program I find the best assembly program which I have written because it gives me an important experience for the future.

I studied that one should better knows different languages and possibilities which we have in the operation system and knows different tools which we use (for example different compiler and linker options). One should better combine all this knowledge and find the best pragmatical way in every new project.

Previous project took over a VOIP ata/phone...90% of the code base was in assembly. It was running on a DSP, so it wasn't assembly with GP registers like ARM/MIPS (where I can write in C and generally compiler does a decent job).. but only a handful of registers so the C compiler sucks. RAM and ROM was limited to 32k each. It handled the obvious part like voice, but also:

• SIP v2
• IVR - interactive voice response
• Networking (DHCP, ARP, DNS, TFTP, UDP, TCP, etc)
• HTTP Server w/ digest authentication - Webpage was actually generated with javascript, since it would be smaller!
• HTTP Client for auto provisioning
• hash/encryption: MD5, SHA1, RC4
• no debugger: printf was your friend...except for couple of projects where we would use the serial port also, those were interesting...

To be honest, I can't claim all the credit. A lot of times, I would inherit a block of code written by someone else. But it only work half-azz and full of bugs.. so instead of finding and fixing bugs one by one, I would just re-write it and make it smaller in the progress.

The most frustrating part wasn't the coding, but the disappointing sales and trying to explain to the sales/marketing guys why we can't add IPV6! sigh...

I had a less than 20 line one that wiped your disk on DOS and windows 3.2 :)

Ahh, I remember doing Real Time Programming on a Motorola Micro Controller. The concepts learned were extremely useful. I just wish I built my unit with a USB plug instead of a serial cable :(

My best would be the "elevator" code which we had to write in microprocessor 8086 lab during our college days. It was the code which spawned over 3 pages while all the other lab programs were around 10 lines. Everyone would hope that it does not appear in lab exams and as murphy's law - I got this in my lab exam. Well, I had to write the whole code myself which I had never done before in the college. Somehow I could get my elevator working and got out of the lab happily.

I wrote a small boot sector that display a message and reboots machines. It is meant to be pushed through PXE to some machines that got stuck.

I wrote a "ping virus" payload simulator. No infection, just a TSR that displays a bouncing ball.

1999 - wrote a Gameboy game (Gameboy Classic and Gameboy Color) entirely in Z80A assembly.

That was long after I had gotten comfortable with C++, so I wrote my own preprocessor to have a tiny notion of a "struct".

Also, the Z80A CPU, which is limited the way it is, has been crippled in the Gameboy and stripped of things like the ix and iy registers, so doing even the most basic tasks was a chore.

And even better, the CPU is not fast enough to replace a sprite by copying its data with a traditional memcpy-like "read from source and write to destination" mechanism, so I wrote a script that wrote program code to update the sprites using "push" instructions, keeping the most commonly used values in the registers.

I wrote a number of different things in assembly over the years, but I think the following three Z80 opcodes in these particular locations in memory are my favourite construction:

poke &bb48, &32
poke &bb49, &45
poke &bb4a, &ae

which translates to:

LD [0xAE45], A

This has the nice side effect of preventing the BASIC loader of an Amstrad CPC464 ^[1] from deleting a protected basic program (saved with ,p) when loaded using LOAD instead of RUN, thus enabling you to list the program contents. It works because the location ae45 is a flag that when non-zero will cause the current program to be purged, but the firmware routine at bb48 (a three byte RST vector) gets called first ( IIRC ^[2], it's some kind of non-essential init.) Couple this with the fact the Z80 accumulator is conveniently 0 when this routine is called, the protection flag will get zeroed before a later routine reads it.

I figured this out in 1986, when I was about 12, I think. If I'd actually bothered to send it into any of the popular magazines of the time, I don't know what would have happened. I would have been DVD-Jon'd, probably... several companies made a ton of money selling complex "deprotection" software.

In 1998, I wrote a simple freeware Autodesk FLI video player .com program for DOS that was exactly 1024 bytes long and was really proud of it when I heard that it got on some CD-ROM snapshot of simtel.net ^[1] or something (I know, they published snapshots of everything regularly, but to me it was quite exciting that my work was publicly distributed on read-only media).

Later on, while dreaming of my own operating system with a checksumming file system (my hard disks got corrupted silently over time), I implemented a simple boot loader, integrated the player and put it on a floppy disk along with an FLI video as a sort of boot-up splash screen.

I never got the motivation to pursue that dream any farther though when I learned about NDAs (Non-Disclosure Agreements) while trying to get information on how to program a graphics card – it came with a $ 500,000 compensation claim in case I broke the agreement, and my parents did not feel comfortable signing such a thing for me (the manufacturer shut down some years later).
And at about the same time, I discovered Slackware Linux...

Well, since I just started reading Programming Ground Up, I believe this is the one:

http://stackoverflow.com/questions/3702979/in-line-assembly-example/3703095#3703095

It's not a complete program, but I'll come back here with something interesting soon enough.

Does redcode count?

I got on the KOTH hill a couple of times before it basically became a game of who could throw the most CPU power into probing constants.

The best was my first, on a 6502-based Commodore VIC 20. Oh, I'd been writing BASIC for a while. It was cool. I'd written some fun stuff. I'd even persuaded my parents to buy me a tape drive so I could actually save the programs. But BASIC was slow, and heck, line renumbering was a chore!

An older kid at school was laboriously typing a whole bunch of numbers, from a magazine listing, into a Commodore PET. I had no idea what he was typing all the numbers for, but I noticed a typo and let him know. He revealed what the numbers meant, and taught me 6502 assembly & machine code.

He had me write a program that moved a character across the screen. In BASIC it would have been a plodding affair. The machine code version, hand-written in assembly and hand-converted to an array of decimal, whizzed faster than the eye could see. I was blown away. I made it loop infinitely just so I could see something blurring by.

Then I wrote another version that moved backwards, and I found out why memmove() needs to sometimes copy forwards and other times backwards, when the memory overlaps. And it was still amazingly fast.

I was hooked on speed. I wrote no more BASIC.

We develops the compact Program for Windows - InstallSimple - creating installation packages Written in Pure Assembler Language (MASM32). You can see it here: www.InstallSimple.com ^[1]