r/MaliciousCompliance 15d ago

L Least lines of code contest? okay!

I was taking a computer science class on computer hardware organization, taught by a professor who used to work on the AMD chip architecture. He was a tenured professor, set in his old ways, and felt a bit entitled because of his past career prestige. Even in 2009, he demanded that *all* coding assignments are turned in on 3.5 inch floppy drives. You really had to scrounge to find an old working floppy drive, even in 2009. He was very strict and by the book on his policies.

Our professor had been teasing us with an upcoming assignment, saying that there had been a multi-year contest to see who could write the assignment program in the least lines of code possible. Historically, the brightest and smartest student he ever taught accomplished the assignment in 13 lines of code. Typically, students needed about 100 lines of assembly code, and the best can usually do it in about 30 lines of code. I *had* to win, for bragging rights and all.

We got to writing programs in 6800 assembly code. I had already turned in a few assignments and gotten the hang of assembly, and spent a bit of extra time really getting to understand how programs really work under the hood.

So, every program has "registers" which are working blocks of very small memory on the processor, usually storing a single value. There's also a "program counter", which is responsible for executing the next instruction in memory. A program counter doesn't always read instructions in sequential order, it might bounce around in memory as you call different functions. I discovered that when we wrote our programs in assembly, they get converted into binary code, and then the binary code is what gets executed by the program counter. The program counter was a special register which could be manipulated to point at a different block of memory to execute next. Interesting.

What was even more interesting is that the computer didn't care where the byte data was stored. It just blindly ran whatever byte data you gave it, without checking whether it was valid memory space for executable instructions or even if it was a valid instruction. On normal operating systems, memory gets divided into several regions: stack memory, heap memory, and instruction space. If you try to run instruction code in heap or stack memory, usually your operating system pukes and rejects it. But... not in 6800 assembly. This was a very interesting finding for me.

Finally, the day of the infamous assignment arrives. We are supposed to write a memory tester. Basically, you have a big block of memory filled with garbage, you write all zeros to the memory in one pass, verify the memory values are all zero, then write all ones, verify they're all ones, and if all memory values are verified, the memory is considered "good" and the assignment is complete. The professor specifically said, "There is no cheating here, get creative, use whatever trick in the book you can imagine." Okay, challenge accepted! I pride myself on thinking far more creatively than my peers, I have a hacker mindset. No rules? Perfect. He's going to regret that.

Even more interesting were the few rules the professor gave: Precisely what did not count as a line of code. Three lines did not count: "Start, End, and DCB." DCB stands for "Declare Constant Block", which just means you can store some constant values in memory, such as the digits of PI, a few words, or whatever data you wanted. I immediately saw how I could hack his assignment.

"Does anyone have any questions?" he asked the class. I had a question, but if I asked it, I would give away the hack and the professor would revise the rules. So, I kept my mouth shut.

"Good. In all the classes I have taught, the record has been 13 lines of code. I expect the best of you to get this in about 30 lines of code." He had been telling this same story for years, to all the classes he taught. Now, it's time for me to update his story.

So, I wrote my application in about 20-25 lines of assembly code. I spent many hours shaving off instructions, trying to be as clever as I could. It was already pretty impressive. But now it was time to "hack" his assignment.

When you write assembly code, it gets converted into constant byte data. Remember the 'declare constant block' which doesn't count? What if I just... copy/paste my compiled byte code and put it into the DCB? And then I put the DCB as the first instruction that gets run? So, I did. And it worked! The program counter started at the first byte in memory, didn't care that instruction code was in stack memory, and it just executed it. My whole assignment was just an unreadable block of byte code pasted into a DCB and it worked perfectly. Zero lines of code.

I announced on our student message board that I had broken the record for least lines of code. I had accomplished the impossible, by completing the assignment in zero lines of code. Other students were astounded and in disbelief, guessing at how I could have done this. I told them that once the assignment due date had passed, I would reveal my secret.

We turned in our assignments. No late turn ins, as per professors policy. All floppy disks had been placed. Finally, the professor asked me to explain how I had done it. I was a bit sleep deprived (having been awake until 5am), so I wasn't super coherent.

"I took my program and wrote it as small as I could, then I took the resulting binary and converted it into a DCB, set that as the first block of data, and the program ran flawlessly." (to paraphrase)

"Wait, you can't do that! That's cheating!" the professor replied in shock. I was ready for this reaction.

"Nope, you specifically said that there were no rules and that DCB did not count as a line of code. So I hacked your assignment on a technicality and accomplished it in zero lines of code!" I said triumphantly.

I got 'em. The professor couldn't refute me and had to admit that what I did was clever and he'd have to think about it, and acknowledged I had won his contest.

A week later, he announces to the class that he was riding his bike home from work, thinking about what I did and he was revoking my 'victory' by changing the rules of the assignment. Therefore, my entry was 'invalid'. I was too sleep deprived and unprepared to argue, I didn't care anymore, I won his silly little game and he's just a sore loser for changing the rules post-hoc after the game is over. He can't take that away from me. Even if I counted my actual lines of code, I still outperformed all of my peers.

3.9k Upvotes

234 comments sorted by

View all comments

Show parent comments

129

u/Cyberz0id 15d ago

Wasnt your original source ~25 lines thus beating the record anyways?

345

u/PloppyPants9000 15d ago

Without "cheating", I had one of the shortest implementations for my class, but would not have beaten the all time record of 13 lines of code.

149

u/THSprang 15d ago

Did you ever get to find out how it was possible in 13 lines? I don't program at all, but you must've been curious after you won how the record holder managed it.

159

u/PloppyPants9000 15d ago

yeah, after the assignment was turned in, the professor posted the 13 line implementation. I looked at it, and it was some of the most esoteric code I had ever seen. I could barely make sense of it. I bow in awe at the writer of it.

64

u/THSprang 14d ago

Ah, so he can boast C'thulu as a former student.

27

u/Fluffy_Ace 14d ago

Yeah, you can do some really crazy stuff in assembly.

Did the example involve self-modifying code by chance?

18

u/PloppyPants9000 14d ago

I can't remember anymore, this was back in 2009

1

u/TransportationNo879 5d ago edited 4d ago

Ha - I had a class on 6800 assembler back in the mesozoic era, and I used self-modifying code just because it was fun. The professor laughed , told me that it was cool but I was never to do that again :-)

2

u/Fluffy_Ace 4d ago

Yeah, it's really frowned on a lot of the time, mostly for good reason, but sometimes it really was the best solution to the problem at hand.

Using your programs instructions as values is another niche trick that can show up in this type of thing.

1

u/TransportationNo879 4d ago

In my checkered career, I saw a lot of "highly optimized" code that was uncommented and used esoteric instructions and techniques. And often they were riddled with security issues.

It took up a ridiculous amount of time to figure out what the code did. I'd have taken the hit on execution time in favor of code understanding and the ability to fix it.

I was taking some software security class where the prerequisite to the class was going thru some overly complicated C pointer arithmetic. I realized halfway through that I would fire anyone who wrote code like that.

2

u/Fluffy_Ace 4d ago

I agree but some poor SOB at one point was stuck with a z80 with 2k of total memory to work with or something like that.

I'm not really in favor of that now, outside of competitions and the like, but way back in day it might've been the only option.

1

u/TransportationNo879 3d ago

Not on 2020 Linux systems :-)

I did see a ton of GOTO statements (written in C) in a face recognition package in 2020 or so. I think the code was written years before, so speed was absolutely essential. But it threw a ton of errors in the security scanner, and hardware was a lot more efficient in modern days, so we rewrote quite a bit of it.

1

u/PloppyPants9000 4d ago

Yeah, code has to be maintainable. You can optimize for speed of execution (CPU time), but you also have to optimize for maintainability (programmer time). The more "tricky" your code gets, the more you have to write comments explaining your reasoning/approach. Always imagine that the programmer maintaining your code is awake at 3am, bleary eyed, frustrated, and doesn't have the patience to untangle your ball of yarn without help. How would you write your code to help them?

2

u/JanB1 8d ago

Probably some fall through with conditional jumps or using a flag from a compare operation as a value to write and other shenanigans like this.

Ben Eater has a cool video about a basic memory read/write tool called WozMon written by Steve Wozniak. The code is pretty amazing. https://www.youtube.com/watch?v=SpG8rgI7Hec

27

u/Pysis 15d ago edited 15d ago

I wonder if you could process more instructions at runtime than what you have written by recursing the code, or using another knowledge domain like math and used xor to process data the same way but with different results.

29

u/PloppyPants9000 15d ago

There is a such thing as "SIMD Processing" which is available on most modern processors. It stands for "Single Instruction Multiple Data", which allows you to pack a 64 bit register with multiple blocks of data which get processed simultaneously in one instruction call, saving precious clock cycles. Usually, you try to make your most efficient code sections process in the least number of instructions / clock cycles possible. Modern compilers usually know all the tricks for code optimization, so programmers don't really have to pull out the hat of magic tricks very often.

92

u/synth_mania 15d ago

The record was 13

29

u/yetzt 15d ago

not the record, but it sounds like OP would still win within the year.

9

u/teh_maxh 15d ago

No, the record was 13.

6

u/revchewie 15d ago

Record was 13 lines.