A Lesson Learned from IEEEXtreme
I recently participated in the IEEEXtreme 8.0 24-hour programming competition. The IEEE Student Branch at UH Manoa hosted this one (I suppose I hosted myself). I’ve done it three years already, and it’s always a very fun experience that I wish more students would come out for. But really, I learned a somewhat important lesson from this specific programming competition: you need to learn how to quickly hack together code.
I actually missed a year before this, and it just so happened that I gained a significant amount of software experience inbetween those years: I completed a fall and summer tour as a Co-Op Engineer at AMD’s austin campus. In that time, I picked up a handful of different languages, frameworks and tools. So in that time, I’d been living in relative luxury in the software development world. I had time, little pressure, and some motivation.
Now the IEEEXtreme programming competition kicked things a little into high gear. Specifically this year I was stuck on a particular problem. This problem, compared to the other problems was pure grinding. There isn’t any special mathematical optimization required for this problem but I got stuck just trying to make the damn . thing.
My friend James Wang put this in concept in an interesting form:
It's important to do things that don't scale in the beginning.
— James Wang (@wangbus) October 22, 2014Scaling meaning building your application so that it can become “bigger” later on. And this is absolutely true! When you first build something you don’ necessarily need to take into account every factor that you’re going to face later one. Sometimes you need to get something out just to get it out, and to get thinking about it. You can always refactor later, but if you get stuck on too many details, you’ll stonewall yourself.
I feel as if many novice programmers have this issue; they’re in this awkward place between coming out as a fresh undergraduate and becoming a full-fledged veteran. We just haven’t learned when to yield to certain things and when to not. Oh well, the learning process isn’t always straightforward!
Here is the problem I encountered for reference:
Assembly Simulator:
Assembly Language is a low-level programming language that is specific to a particulars computer architecture. Each command has a specific structure:
label COMMAND OPERANDS
The commands are represented by mnemonics and perform low-level arithmetic and logical operations generally computed by an Arithmetic-Logic-Unit (ALU). Operands include constants, registers, and addresses that can trigger operations. Labels are used to mark the line of a command so that the ALU can jump or branch to that location to implement higher-level operations such as an if-statement or loop.
Task:
Write an assembly language emulator for the Xtreme-8000 processor. The processor consists of an ALU and a register to store comparisons (only set using the COMP command). There are no accumulators, temporary data registers, or temporary address registers. The processor has a maximum of 256-byte memory that it can address through its commands. The full list of commands is:
Input
The input will contain:
1) 0 <= Size of memory in bytes <= 0xFF
2) Program to execute
a) Each line has an optional label, a command, and a list of
comma separated operands (as needed for each command).
Output
Output the result of any print statement.
Note: There is a newline character at the end of the last line of the output.
Sample Input 1
0F
PRINT 00,0F
MOVE #FF,00
PRINT 00,0F
MOVE 00,01
PRINT 00,0F
ADD 00,02
PRINT 00,0F
ADD 01,02
PRINT 00,0F
Sample Output 1
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
FF 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
FF FF 00 00 00 00 00 00 00 00 00 00 00 00 00 00
FF FF FF 00 00 00 00 00 00 00 00 00 00 00 00 00
FF FF FE 00 00 00 00 00 00 00 00 00 00 00 00 00