Low-level is easy
Blog<br>Site<br>𝕏<br>Feed
Low-level is easy
January 7th, 2008
My previous entry has the amazingly interesting title "Blogging is hard". Gee, what a wuss, says the occasional passer-by.<br>Gotta fix my image, fast. Think, think, think! OK, here's what I'm going to tell you: low-level programming is easy. Compared to<br>higher-level programming, that is. I'm serious.
For starters, here's a story about an amazing developer, who shall rename nameless for the moment. See, I know this amazing<br>developer. Works for Google now. Has about 5 years of client-side web programming under his belt. And the word "nevermore"<br>tattooed all over his body (in the metaphorical sense; I think; I haven't really checked). One time, I decided that I have to<br>understand this nevermore business. "Amazing Developer", I said, "why have you quit the exciting world of web front-ends?" "I<br>don't like it", says the Amazing Developer. "But, but! What about The Second Dot Com Bubble? VC funds will beg you to take their<br>$1M to develop the next Arsebook or what-not. Don't you wanna be rich?"<br>"I really don't like web front-ends very much", he kept insisting. Isn't that strange? How do you explain it? I just<br>kept asking.
Now that I think of it, he probably was a little bit irritated at this point. "Look, pal", he said (in the metaphorical<br>sense; he didn't actually say it like that; he's very polite). "I have a license to drive a 5-ton truck. But I don't want a<br>career in truck driving. Hope this clarifies things". He also said something about your average truck driver being more<br>something than your typical web developer, but I don't remember the exact insult.
Now, I've been working with bare metal hardware for the last 4 years. No OS, no drivers, nothing. In harsh environments in<br>terms of hardware, by comparison. For example, in multi-core desktops, when you modify a cached variable, the cache of the other<br>processor sees the update. In our chips? Forget it. Automatic hardware-level maintenance of memory coherency is pretty fresh<br>news in these markets. And it sucks when you change a variable and then the other processor decides to write back its<br>outdated cache line, overwriting your update. It totally sucks.
A related data point: I'm a whiner, by nature. Whine whine whine. You've probably found this blog through the C++ FQA, so you already know all about my whining. And it's not like I<br>haven't been burnt by low-level bugs. Oh, I had that. Right before deadlines. Weekends of fun. So how come I don't run away from<br>this stuff screaming and shouting? Heck, I don't mind dealing with bare metal machines for the rest of my career. Well, trying<br>out other stuff instead can be somewhat more interesting, but bare metal beats truck driving, I can tell you that. To be fair, I<br>can't really be sure about that last point – I can't drive. At all. Maybe that explains everything?
I'll tell you how I really explain all of this. No, not right in this next sentence; there's a truckload of reasons (about 5<br>tons), so it might take some paragraphs. Fasten your seatbelts.
What does "high level" basically mean? The higher your level, the more levels you have below you. This isn't supposed to<br>matter in the slightest: at your level, you are given a set of ways to manipulate the existing lower-level environment, and you<br>build your stuff on top of that. Who cares about the number of levels below? The important thing is, how easily can I build my<br>new stuff? If I mess with volatile pointers and hardware registers and overwrite half the universe upon the slightest error, it<br>sucks. If I can pop up a window using a single function, that's the way I like it. Right? Well, it is roughly so, but there are<br>problems.
Problem 1 : the stuff below you is huge at higher levels. In my humble opinion, HTML, CSS, JavaScript, XML<br>and DOM are a lot of things. Lots of spec pages. A CPU is somewhat smaller. You have the assembly commands needed to run C<br>(add/multiply, load/store, branch). You have the assembly commands needed to run some sort of OS (move to/from system<br>co-processor register; I dunno, tens of flavors per mid-range RISC core these days?). And you have the interrupt handling rules<br>(put the reset handler here, put the data abort handler here, the address which caused the exception can be obtained thusly).<br>That's all.
I keep what feels like most of ARM946E-S in my brain; stuff that's still outside of my brain probably never got in my way.<br>It's not a particularly impressive result; for example, the fellow sitting next to me can beat me ("physically and<br>intellectually", as the quote by Muhammad Ali goes; in his case, the latter was a serious exaggeration – he was found too dumb<br>for the US army, but I digress). Anyway, this guy next to me has a MIPS 34Kf under his skull, and he looks like he's having fun.<br>That's somewhat more complicated than ARM9. And I worked on quite some MFC-based GUIs (ewww) back in the Rich Client<br>days; at no point I felt like keeping most of MFC or COM...