Apr 11, 2013 twenty five past seven pm

I first learned to program on a TI-59 programmable calculator.  My dad "the physicist" would bring it home on weekends and I would monopolize it for the next two days.  I'd make games and type in programs from Byte magazine.  It was a magical device. I don't know what it was about programming that enthralled me, but I was obsessed with it.  It was an odd skill to have back then, even at the level of programmable calculators.  Computers were still the stuff of science fiction or only owned by huge companies or universities and housed large noisy air conditioned rooms with punch-card machines.

One summer the college got two Commodore Pet computers that were destine for the local High School.  My friend, Tom McFarlane and I spent that entire summer in the computer lab programming those Commodore Pet computers.

It was my first experience with BASIC and it blew the socks off of the TI-59.  Tom and I devoured everything about those Commodore Pet computers.  We wrote every game we would could think of from Space Invaders to Astroids to Space Wars to little platformers (although we didn't know that's what they were called).  We challenged and pushed each other and became masters of the PEEK and the POKE.

I do blame the Commodore Pet from one nasty habit that's followed me for over 30 years.  Tom and I realized that if we removed all the comments (the REM statements) from our BASIC code, the game would run significantly faster.  To this day, I find myself deleting comments or whitespace under some misguided pavlovian notion that my code will run faster.

The summer ended and the Commodore Pets made their way to the High School, were I was starting as a freshmen.

As I continued to read about programming and computers (mostly in Byte magazine) this odd and strange concept kept coming up: Assembly Language.  What was it?  How did it work?  And more importantly, what could it do for me?

I started to realize that assembly language was real programming.  BASIC was just an imitation of programming.  A layer that sat on top of this thing called Assembly Language.  You weren't really programming the computer if you weren't programming it in assembly language.  That was getting right down to the metal and I had to know what it was.

Lore said it was fast.  Faster than BASIC and this was very appealing to me.  We were pushing the limits of BASIC, removing features from our games just to speed them up.  If assembly language could help with that, even a little, then it was something I had to learn.

Armed with the knowledge that the Commodore Pet used a 6502, I spent the weekend hand writing this program that would fill the screen with @-signs.  I wanted to see how fast this assembly language really was.  I wrote the same program in BASIC.  I needed a baseline.

After class on Monday, I headed to the computer room and found a free Pet computer and typed in the BASIC program. It filled the screen in a little over 1 second.  Fast.  Could assembly language top that?

I typed in my little assembly language program and entered the SYS command to start it executing... and... nothing.  The machine locked up.  No error message, it just locked up.  Odd.  I power cycled the Commodore Pet, started over and soon found my mistake.  Program entered.

My finger poised above the ENTER key.  I was trying to remember how fast the BASIC program filled the screen. I need to be able to tell if assembly language was faster.  I might need to run several tests, maybe add a timer, just to be sure.

I hit the ENTER key.

The screen instantly filled with @-signs.  Instantly.  So fast that I could not even begin to see them being drawn on the screen.  One moment the screen was blank, then next instant it was full of @-signs.  Instantly.

I just stood there.  "Holy shit" I said to myself.  My heart was pounding.

This truly was a religious experience.  Someone had pulled back the curtain to heaven and given me a glimpse of God.  The speed was staggering.  Stunning.  I had no words for it.

That was the last day I ever programmed in BASIC.  Assembly language was my savior.  I gave into it completely.

I was changed forever.

Other people's comments:

Posted by Paulo Radtke on Apr 11, 2013 five past eight pm

Ah, the joy of finding out how fast a program could be. Good days, indeed.

Posted by Mr Hoatzin on Apr 11, 2013 quarter past eight pm


Posted by WiredFromJava Jason on Apr 11, 2013 twenty five past eight pm

I remember that same experience with assembler... Especially when trying to mimic C-64 sprites and the screen scrolling - assembler was the only way to go (I'd combine MASM with my Borland C projects).... Man, this brings back memories.  Thanks Ron.

Posted by Nathan on Apr 11, 2013 half past ten pm

Is it stlll the case that assembly language is faster than the modern high level languages?  

Nowadays wnould you rather code in objective c or asm? Why?

Posted by zenshade on Apr 12, 2013 twenty to seven am

Not sure if you're serious or not, but in general the gap between ASM and high level language speed will get larger over time, not smaller.

There are some exceptions, like gcc and Intel's compilers, where they're putting a lot of effort into optimizing as much as possible, but usually the philosophy is to just take advantage of faster hardware speeds to add better abstraction levels.  ASM is as fast as you can get.

That said, its still possible to write ASM programs that are even slower than Visual Basic, if you don't know what you're doing.

But I suppose your point is with today's hardware, the higher level languages can easily hit 60 frames/sec, with lots of time in between for game logic.  So yeah, ASM doesn't really make sense, unless you simply enjoy thinking at the computers hardware level and knowing that you can code something as efficiently as is possible.  And lots of people do,

Posted by Leak on Apr 12, 2013 twenty five past nine am

Writing code in assembly isn't quite the silver bullet it once was anymore; it doesn't really make sense to hand-optimize parts of the program that are hardly ever used (not to mention that debugging and modifying assembly code is a lot more complex than high level code), and even for tight inner loops it probably makes more sense to use compiler intrinsics instead of inline assembly or linking with external libraries written in assembly.

Also, another reason on early computers to use assembly for everything - to fit your program in 64kB of RAM - is usually no longer a problem.

If you're interested, take a look at Fabian Giessen's (aka Ryg of German demo group Farbrausch) recent 16-part series about optimizing the heck out of a C++ 3D Software Occlusion Culling example that Intel released, all without resorting to assembly.

Posted by tbone on Apr 12, 2013 ten past ten am

This is absolutely true! I worked with some of the smartest people I've ever met and we were trying to optimize the dispatch loop of a javascript bytecode machine. The version compiled from C was 7 asm instructions. No one could make it faster.

One of the instructions was even effectively a NOP (no operation), and removing it resulted in the same behavior, but at a slower speed! To this day I can't explain why that would happen.

Morale: Never underestimate the amount of thought, research and iteration that has gone into a code optimizer.

Posted by Anony on Apr 12, 2013 five past eleven am

There is a decent chance that the NOP allowed the CPU pipeline to remain full instead of forcing a flush. Can't be sure without the code but that would be my guess.

Posted by Owen Shepherd on Apr 12, 2013 five to ten am

The thing about all programming is that, in general, high performance code comes at a cost to readability and complexity. How much this is true depends upon the language - some languages provide abstractions which can provide code clarity and performance simultaneously. This is very true of Fortran and C++; less true of C, and basically not at all of Assembly.

This combined with the capabilities of modern optimisers means that, for reasonably readable code, the compiler can beat reasonably readable assembly. Beating the compiler often results in complicated, convoluted, hard to read code.

Convoluted, hard to read code is never what one wants for large projects, so large assembler projects (the few of them that there are) are almost always written in a very simple, straight forward assembly "dialect" which the compiler optimisers can beat, and are like largely native code projects in that only tight inner loops are heavily optimized

Posted by Ron Gilbert on Apr 12, 2013 quarter to eight am

I don't code in ASM anymore.  Unless you're writing the very core of some tight loop that's going to be called a hundred thousand times a frame, there isn't much of a reason to.  Compilers these days are very good at optimization.  Also, with the way modern CPUs pipeline instructions, writing fast ASM can get tricky since you need to write your instructions in an odd out-or-order sequence for optimal speed.  Compilers love that stuff.  Humans don't.

Posted by Jubanka on Apr 11, 2013 ten to eleven pm

A person who is more than casually interested in computers should be well
schooled in machine language, since it is a fundamental part of a computer.
-- Donald Knuth

Posted by Beef on Apr 12, 2013 five past eight am

To add a caveat to that quote:  (x86) assembly language is machine language for a machine that no longer exists. As Ron said in another comment, the instructions are translated, picked apart by the processor and executed in executed in a completely different way than how you originally wrote them down.  Add multicore to the mix and you have a complete screwed up situation.

I would certainly consider teaching an ASM class, but stick to microcontrollers or other simple processors. Something where the machine language is more accurately mirrors what happens inside the processor.

Posted by Corey Cole on Apr 13, 2013 ten to seven pm

This is a problem I've run into in recruiting.  There is no good reason to program in ASM these days, so people don't learn it.  But learning ASM is still important.  Along with the language syntax, you will learn how loops and other code structures actually work.  You will learn about boolean algebra, how negative and floating-point numbers are stored, what data structures really look like, and so on.

I used various assembly languages for most of my early work.  My ASM background was critical to getting a job at Sierra On-Line, where my first task was converting SCI from 8086 to a 68000 architecture.  Besides the thousands of lines of ASM I had to hand-convert, there were issues with big-endian vs. small-endian integer storage, segmented vs. flat memory space, and details of the graphics systems.

I would still recommend that anyone who is serious about programming should at least take a class in some assembly language and/or write a few practical ASM programs.  You won't be complete without that knowledge.

Posted by David Hunter on Apr 12, 2013 five past midnight

I had a very similar experience with the Apple II and the Commodore 64. Both used the MOS 6502.

I'm told that processor was hand-drawn at the transistor level, and that the first revision worked -- aside from an instruction of death that shorted power to ground.

Posted by taumel on Apr 12, 2013 five past two am

My experience was both similar and different at the same time. First entering listings from magazines each time before you could play a game on the C64 (no floppy, no dataset in the beginning). Depending on the game you needed to enter the code correctly but also distract yourself good enough in order to avoid spoilers (if it was an adventure). Then writing a few games in Basic.

But the real kick came with the A1000, 68000 assembly, a borrowed/copied hardware manual, the Kuma-Seka-Assembler (later on AsmOne) and a couple of other tools. This, was truly amazing and opened the door to a whole new world. :O)

Posted by wysiwtf on Apr 12, 2013 five to three am

6502 ASM eh?
Go make a Demo about it.

Posted by Terry A. Davis on Apr 12, 2013 three am

I wrote a ring-0-only operating system you might like.  TempleOS

Posted by Someone on Apr 12, 2013 quarter to five am

I have nothing useful to say, just that TempleOS (formerly SparrowOS) is an amazing project.

Posted by Arminator on Apr 12, 2013 half past three am

I had the same feeling reversed, only about 30 years too late.

I got a Commodore 64 as a christmas present as an 8 year old kid. I tried to understand the user manual, but only managed to either just copy the example BASIC programs from the manual, or limit my programs to "Please enter your name:" -Armi "Hello, Armi" kind of stuff.

The whole graphic bitmap stuff was too complex for my mind at that time, especially since there were already games readily available on that thing that kept me distracted (by the way, let me personally thank you for Maniac Mansion, another reason that kept me from learning that machine...).

So I didn't really "get" the power (or lack thereof) of the C64, until my last move, and found the programming manual of the C64 again. Skipping through it (and having a graduate in computer science today), I finally understood the machine. But didn't have the time to try it out during the move.

Now this year in January, 30 years later, I took a class in Microcontroller programming.
It was just an example program, that had five integer numbers stored in a table, and that the HC12 should add up.

We wrote it in assembler and it was as fast as I expected a machine to process that kind of thing.

Then the professor asked us, to do the same program in C with the IDE that came with the experimenting kit.

A once elegant 20 line Assembler program turned into a 250 line compiled monster. And instead of adding stuff directly in the Accumulator, the compiler decided it would be a good idea to move stuff around on the stack. It was awful to watch how the processor looped senselessly to transfer numbers from one memory to another, when our Assembler program did it in one instruction.

I now know what I will do, when I have some spare time. I'll dust off my C64, and try all the stuff I wanted to try as a kid, but were unable to comprehend just then.

Posted by Hoffmann on Apr 12, 2013 quarter past six am

try to declare your variables as:
register int x;

if your microprocessor has a good C compiler (many microcontrollers don't tough) it will do all the calculations that involve x in the accumulator.

But really, assembly will always be faster, but in C there are a lot of stuff they don't teach that allow you to go more into the hardware than you think its capable of.

Posted by Someone on Apr 12, 2013 twenty past six am

250 lines?
you don't know how lucky you are ;)

try (just for fun) to do the same in Java (including the current corporate used framework (or better frameworkS as everything today is a framework ;)
Every bank/insurance firm has its own way...

my wild guess is, you end up with a package about 20 MB in size... (including all dependent libs of course)

Posted by Someone on Apr 12, 2013 twenty five past six am

"...awful to watch how the processor looped senselessly..."

awful to you,
pure joy for every CPU producer worldwide :D

Posted by zenshade on Apr 12, 2013 ten past seven am

That's a wonderful story.

I had an Apple II that I programmed in basic (too slow for anything non-textual), but I lacked the patience/knowledge to dive into ASM and find out what it could really do.  Times were different back then (1980).  Unless you knew other geeks or had a geeky computer store close, you were on an island and might never be exposed to Byte or some of the other mags that gave you the contextual picture of what was possible and what tools were available.  And there was virtually NOTHING on the library shelves to help you back in those early days of personal computing.  Such was the case with me.

If I could go back in time, I'd tell that geeky teenager to get his ass out the door and go find some other computer geeks to help him learn and connect him with resources.  I pretty much lived in the arcade, and was absolutely certain I could make better games than what I was playing.  Shoot, back then even bad games were turning kids into millionaires overnight.

I eventually did create some games on the Atari ST in c (probably publishable, but nothing I was overly proud of), but at that point college and family life in general took over.

I have this silly notion in my head that there's still a market out there for side-scrolled 2D games done really well in ASM/c.  And I have a strong urge to simply chuck my successful web programming career, return to that simpler time and write those games.

Posted by pheo on Apr 12, 2013 ten past noon

There is a lot of fun and a lot of learning to be had from assembly level programming. Im a tinkerer and i love digging into the instruction set of the various microcontrollers ive played with over the last few years. i love risc sets like ARM and the micros from TI that ive gotten (except Thumb!) The most interesting part about assembly is learning exactly how the machine works and what it is capable of. I wrote a line of inline asm to test the cool random number generator (DRG) on my new ivybridge machine. Same for AVX a while ago when i got a sandy bridge laptop. Im looking forward to using (and really having the control to USE) the new TM extensions on Haswell.

Im 26, so when i was born, you could get a 386, i can't imagine what is was like to make the switch to low level and see the golden age machines perform at their limits. Real-mode seems like a lost relic to me...

Posted by BPT on Apr 12, 2013 five to eight pm

still fun to write asm code from time to time, but thankfully we don't have too as often.

Posted by Davide on Apr 14, 2013 quarter past five pm

It was pretty similar to the experience of my first CUDA kernel..

Posted by tradesman on May 6, 2013 twenty to one am

In all honesty it was an excellent detailed post even so as with most wonderful copy writers there are many points that might be labored on. However never ever the actual a smaller amount it absolutely was intriguing.

Posted by Leandro Pezzente on Jun 1, 2013 quarter past six pm

Actually , in interpreted or scripted languages , like JavaScript ... deleting comments ( and tabs and spaces and blah blah blah ) will make it download sooner and run faster.

Creative Commons License
Hey! Pay attention! Except where otherwise noted, this site is licensed under a Creative Commons License.