I think asm-app will forever be in my 'to-do' list, simply because I never had any project in mind that would require benefits I get with assembler...
Simple description of problem you've solved in assembler would be nice, and especially why you choose asm over high-level languages...
Because it was on a TI-83...
Because I wanted to do like the guy on project-euler who solves every problem using ASM...
More seriously though, there are nearly no project that demand programming it only in ASM (except maybe for old embedded platforms), but there are a lot where there is a need to use ASM for a small bit because you want to use specific instructions that the compiler might not even know about.
I did a couple of all-assembler apps in college when I was learning x86 ASM. I did a simple bit map editor with mouse support in VGA mode 0x13.
I have built some applications in PIC16 assembly, simple because I had no compiler available. This is of course embedded programming; I don't know if you have that in mind. For small 8-bit microcontrollers you gain benefits for programming in assembly, both in size reduction and speed execution. For bigger projects however, even in the embedded world, it would be a mistake to code only in assembly. Assembly would only be used in small parts of the program (for example in time critical paths or to access the processor's registers).
I did a lot of x86 assembly. Database sorting, Fractal generation, physics simulations, etc. Even a few business apps. All for one reason. SPEED. That's back in the 8088 at 4.77-10mhz days. Compilers weren't as smart either, so assembly carried a much greater speed advantage than it does now. 640K RAM was never a serious limitation on those machines. Ran out of processing power well before then.
I used to write things like TSRs DOS hardware interfacing purely in assembler. And I've done lots of embedded work purely in assembler.
They're both pretty much just historical curiosity nowadays - there is only a tiny sliver of the embedded development business left using hardware so meagre that all-assembler development is worthwhile.
If you want to experiment with assembly language then an embedded system kit (like the Arduino) might be the way to go. These tend to be much simpler to get an assembler program up and running than a modern O/S.
I'm a little ashamed to admit it, but back in the day I wrote an auto dialer for my IBM PCjr using the screaming hot 300 baud modem in 8088 ASM.
A decade ago I did some TI-82 and TI-83 calculator programs in Z80 assembler, including a trainer for a game. It was the only available language... :-)
I've also a faint memory of creating some Terminate and Stay Resident (TSR) program in 80386 assembler back in the MS DOS days.
You should think about entering the 8-bit games programming competitions that happen every so often. They're usually about writing an 8-bit game (C64, Spectrum, Amstrad CPC, Atari, etc) within 1, 2, 4 or 8 kilobytes of binary. A really good way to force yourself to program on the metal.
I wrote a PDP-11 simulator in 8086 assembly. Trust me, there's nothing in the world that's more frustrating than debugging variable length op-codes on an original IBM PC. You could tell that there was a bug in your code because the machine would hang. Time to reboot from 5 1/4 inch floppies!
Good times, good times....
I wrote an assembler for my C=64 in BASIC. I was going to use that to write an assembler in assembler, but by that time I'd saved up enough money to buy PAL and it was so much better than anything that I could write.
I write assembly every day for my job. I write applications for radio based water meters. I deal with sampling rates, clocking schemes, RF chip initialization and data transmission. I have written ASM primarily on MSP430 microcontrollers from Texas Instruments.
I've done this.
The software was to drive a digital clock built around a PIC 16F84 microcontroller. I chose assembly because I didn't want to buy a C compiler for the PIC.
It's a good experience and makes working with a higher level language on the microcontroller easier because you understand how things, such as interfacing with the onboard peripherals, work behind the scenes.
I'm now using AVR-GCC on the AVR controllers, but many of the concepts are still the same.
I've written an instruction level debugger/disassembler purely in x86-64 asm to learn about 64-bit system call mechanism in Linux and Mac OS X.
i wrote - with a friend - an educational game for the Apple ][ in 6502 assembly language, complete with a custom disk I/O subsystem, a graphical user interface, vector-based fonts and animation, and a 500-question database, all on one floppy disk (two-sided). Assembly language was required for code size but mostly graphics and I/O speed.
later i wrote a 2D CAD system on the C64 in 6502 assembly language, again for size and speed.
these days, i don't do anything that requires assembly language (but i would if necessary), but i think the 2-3 years working at such a low level (even employing OO concepts) advanced my education tremendously.
I've created an operative system in ASM. Which has a Exception Handler, and soon Process handler and some other stuff, i guess that is a complete app? :)
The last asm code I wrote was not a complete app but a few subroutines that required high optimization using Altivec (PowerPC CPU) and SSE (Intel CPU) code. The goal was to have a fast scaler for video data in 4-2-2 YUV representation, for real-time display in a Mac OS X TV application. Apple's Quicktime had code for it, but its output looked bad when scaling down pictures with diagonals in it because it simply threw out entire lines. My code did instead average the input values of all input lines, making the resulting picture look much better antialised. Such area (SSE code) will always remain a domain of hand-optimization, I guess.
Another area where asm is needed is linkage code for compilers and their runtime environments. Not full apps, either, though.
And many years ago I actually wrote entire apps in Asm, e.g. a disassembler and debugger for 680x0 code, for Atari ST machines. Assembler was necessary there because there weren't many high-level languages around in those times, and even those that did exist had no support for accessing the CPU registers directly, which a debugger clearly needs.
Other apps I wrote that involved a lot of assembler coding were runtime libs for a Modula-2 development system, a virtual machine environment, drivers for MSDOS, CP/M and embedded systems.
These latter examples are all hardly requiring asm any more, other than a few subroutines to access special features of the CPUs.
So, if you really want to check off that "wrote an asm app" item, I suggest you look into programming on small embedded CPUs (even though most modern ones now even offer compilers for them), write an app that relies heavily on SSE code, or, as others suggested, code on those old platforms (C-64 etc.) where there were simply no high-level devents available for writing fast and efficient code.
Good luck :)
My friend and I constructed a z80 based, standalone debugger the could relocate itself to another location in memory. This was on an ol' trash 80 model 1.
It had software based single step capability, so you could actually use it to step through the rom, or debug the debugger.
Semi-relevant:
Somebody thought it a good idea to write an xml parser in ASM. I shudder at the thought of even beginning that project...
I wrote lots of Z-80 assembler back in the TRS-80 days using EDTASM which was a Editor / Assembler from Microsoft that I loaded from cassette tape. I've also done some PIC and other microcontroller stuff. I never really got into x86 assembler.
A related question might be: "Have you ever written machine code without an assembler?"
My very first "computer" was a kitset circuit board with a RCA CDP1802 microprocessor. It could display a few things on a 2 digit 7 segment led display, read a hex keypad, flash a few single leds and modulate a speaker. I later added a few I/O lines that could be used to control external devices. I spent more hours than I'd want to admit to writing assembler and hand compiling it into hex. :-)
Now I spend my days writing business apps in C#. I enjoy it but I also miss working with hardware and lower level software.
It was a long time ago (back in the days of MS-DOS 6), but yes. It was a PCX image file viewer. PCX was a fairly easy format to decode, and I was used to putting inline ASM code in my c++ apps to do graphics anyway, so I figured I'd give it a shot.
Not really an app, but I wrote a utility to read a text file containing decimal digits (arbitrary length number) in the millions of digits and converted it to a text file of the same number represented in hex. It used no division and was really fast. Beat out the arbitrary length calculators available on the net by orders of magnitude.
He who hasn't hacked assembly language as a youth has no heart. He who does as an adult has no brain.
-- John Moore
no idea who he is, but anyway
by the way, I do use it al the time to write toy operating systems started out by z80 jumped to 386 and now sometimes I dream about ARM
Yes, I wrote an encryption/decryption app implementing Bruce Schneier's 'Blowfish' algorithm in IBM 370/Assembler for VM/ESA and zVM on IBM mainframes.
Why assembler? I needed the speed. I didn't have a C compiler available. It was used for several years until the company got rid of the mainframe!
Sure, I've written lots of pure ASM programs. First on a Z80 system (TRS-80 Model I), then on the IBM PC. It is not that bad once you get into it. However, I have yet to do a pure ASM windows app. :D
You can check out some of my 256-byte games to get an idea what these programs look like. There is commented source code on the site you can look at.
Hope this helps.
My first assembly-language programs were for the Commodore 64. I used assembly because interpreted BASIC programs on the 1 MHz 8-bit 6510 CPU were sooooo sloooooow.
When I first picked up an IBM PC (original: ~4.77 MHz 8088), I used assembly for 3 reasons. At first, it was mostly for the same reason as on the Commodore (although slightly less so). Additionally, I discovered that Intel 8088 assembly was almost as easy as BASIC on the C64, so this kept me working in assembly a lot. Like most DOS programmers back in though days, though, I soon found that much of what slowed me down and limited what I could do was DOS and the BIOS themselves, so before long I began writing interrupt handlers to replace or supplement functionality provided at those levels. I even replaced the hardware keyboard interrupt handler with one that gave me hotkey access to tiny utilities I had written that I used frequently (hex to character input, memory examiner, PSP walker, video-mode changer, etc.).
Since machines have sped up, and I learned C and its derivatives, I've found very little use for assembly, except for a few inline assembly routines where hand-tuned assembly was needed for speed. One example is a 192-bit floating-point type that I implemented almost entirely in inline assembly because it would have been both much slower and much more complicated in C++ (which is what the rest of the project was in). It would have been more complicated because C++ doesn't provide access to rolling instructions (e.g. ROL, RCL, ROR, RCR), or access to the carry bit, for "long" additional and subtraction.
I once wrote a simple 3D engine (pre MMX, SSE, and GPU) purely in assembly, but found that the speed-up (about 4%) and executable size difference (about 12%) weren't worth the costs of maintaining the more complex and way longer code (about 2.7 times the size, in bytes).
I wrote a small program on a PIC12 which was acting as glue logic. It took a couple of signals from the main controller on one circuit board, and turned these into a sequence of other signals which went to a differnt circuit board.
Why assembler? Because the PIC12 is tiny - 1 Kb of code space, 25 bytes of RAM, and a 2-level stack. (I'm not aware of any C compilers for it).
My first complete ASM program was written back in 1986 on a Sinclair QL in 68008 assembly. It was an encryption program using a pseudo-random key generator. I even managed to sold through the french distributor called Direco (importer of Sinclair products in France at that time). Complete with GUI and all that.
The last time I wrote entire apps in assembly language was for the Apple II. I think the last app I wrote was a brute-force solution to the Knight's Tour. It ran for three weeks, night and day until the machine locked up.
The usual reasons for writing stuff in ASM are tiny machine, no OS, lack of compilers, etc. Lets see...
If you do any work with compilers, it's good to be handy with assembler.
I wrote a few boot sector intros and a boot sector game (columns) for the Atari ST. I chose assembly since it was the only option for fitting the entire app in less than 512 bytes.
At a major Canadian bank we wrote the whole banking system, from scratch, using IBM main-frame Assembler language. Development started in the early '70s and involved maybe 60 developers on the application side, and maybe a few dozen on the systems side. It is still running well (2009). It now includes a reporting subsystem written in PL/I that was added later. Strangely enough this part didn't turn out to be any easier to maintain :-)
Reasons for picking Assembler (as far as I can recall):
concerns about performance of higher-level languages - at that time we needed to be able to run the whole bank on a 2 Mips machine
concerns about reliability of compilers - what happens to your app if there is a bug in the compiler, or a new compiler release comes out?
ease of access to system functions - these are always supported by Assembler language, but often not by higher-level languages
this Assembler has a very powerful macro capability, so effectively we were able to design our own transparent higher-level language
The system was fast - here is a quote from http://www.c2.com/cgi/wiki?BmoMech : "In the early 1980s, the average Mech transaction had a path length of some 48,000+ AssemblyLanguage instructions." Note: that means machine instructions! Assembly Language is 1:1 with machine instructions.
By the way, this was the first (and, to my knowledge, so far only) production system built using Flow-Based Programming - it was used extensively for the batch part of the system.
More material can be found on http://www.c2.com/cgi/wiki?BmoMech - it's a fascinating bit of computing history!
I'm a huge fan of the 6502 processor. I've written a few NES game hacks and some simple NES demo's from scratch, showing things like writing to the VRAM and capturing and acting on joystick action.
If you're looking for a fun hobby project, 6502 ASM is excellent!
I created complete games in it. This was on the Amiga. Games created in C were just too slow. Also, only in assembler could you kick out the entire OS and use all available memory. ah, good old times.
on the C64 I created demos in assembler.
Last thing I did in assembler was on a pocketpc where some routines which had to be executed quick. (like screenclears)
Yes, and I enjoyed every second of it. I have mostly used x86 asm. I recommend doing something little in asm. It's not hard at all if you make e.g. a MS-DOS console program that outputs primes.
What I have only managed to do with asm code is really tiny stuff (256-byte intros are about the largest projects I ever manage to finish), really low level stuff (a toy OS booting from a floppy with a simple shell) and learning C from bottom up (seeing the registers and the stack in a debugger quite efficiently teaches what a pointer is, for us too-smart-for-books types).
And obviously you need to use asm when doing stuff for the C64, Atari VCS and other stuff designed for real men who actually need to shave. I made a simple drum machine for the VCS but that wasn't even programming in asm, more like mending the CRT electron beam.
Yep, back in the late 80's I had a gig as a games developer for Jeff Minters' old company Interceptor Micros. We were working with Atari ST & Amigas, developing everything in 68000 assembly. It was a lovely chip and a beautiful instruction set.
When I ended up getting a job developing for 286-vintage PC's I thought I'd continue with the assembly route, but after working with 68000 code, the x86 instruction set came as a nasty shock. I couldn't believe how constrained it was.
After that it was C->C++->Java->C#. Sadly I can't see assembly being widely used, outside of niche areas, for much longer.
I learned Z80 Assembler language at the university.
Then I wrote a Z80 Simulator in x86 assembler, but actually "cheated": I wrote the complete thing in C, then took the compiler-generated ASM file and "optimized" that by hand. And it really did run faster (replaced all calls with jumps, stored everything in registers...).
No practical use for it, it was just for the sake of learning.
I think I'll never write x86 assembler anymore, but it's very interesting to know how a CPU works internally, and how much faster software could run.
Even on normal PC hardware, ASM still has one obvious area of use - accessing SIMD instructions (like SSE). Some compilers expose intrinsics but it is one place you can legitimately write an algorithm in ASM with good cause - 4X speedup in your inner loops is perfectly possible and in a data-crunching application that's quite relevant.
I had coded an very simple (working) / fast raytracer (with SSE) in assembler under linux, but i decided to bring the project underground because it wasn't worth the effort to write all in assembly because you can't change anything that easily.
I wrote it in Assembler because i just wanted to see how fast this program might run.