Stats for nerds
1recommend
5mentions
5people
2019–2026years
20% recommend80% neutral
Mentions per year
What Hacker News says
- And you can witness the glory of swtch() and the original "You are not expected to understand this" comment.
Highly recommended.
- Oh my. I am not sure I'm the man.
Executive summary:
286 protected mode gave you 16 MB of memory space, but it still had mandatory segments. Usable but it needed hard work and careful thought.
IIRC, that is why the 286 version of MCW Coherent OS still only allowed a maximum program size of 64 kB of code -- plus 64 kB of data. Very limiting. OK for early-Unix-style (say up to UNIX V6, of Lions Book fame and "you are not expected to understand this" comment.)
386 protected mode gave you 4GB of space, and you could choose the segment size, which meant everyone chose a segment size of ALL THE RAM PLS KTHXBYE. That meant you got flat addressing: all pointers could be flat 32-bit INTs. Simples!
The 386 also added the ability to seamlessly jump from 8086 mode to 386 mode and back.
The 286 intended that to be a one-way trip. DR and others found a loophole (IIRC the `LOADALL` instruction) and a way to exit 286 mode again but it forced a full CPU reset, so it was slow.
Not only did the 386 make it easy to get in and out of 8086 mode for DOS binaries, it natively supported multiple concurrent hardware-assisted 8086 VMs, plus memory management so you could keep most of DOS's 640kB free. So, win for protected-mode code, win for DOS code.
Intel aimed to please the DOS folks, and to alleviate jealousy of the 680x0 and its nice flat memory space, and make it easy to port UNIX and other memory-managed OSes over from minis and workstations.
TL;DR
The 286 protect mode was meant for 286 native OSes and it was not easy to run 8086 stuff, or change modes. Plus, segments, which everyone hated.
The 386 protect mode optionally got rid of all the stuff that people disliked about 16-bit x86 and offered alternatives that rivalled other platforms than x86.
Biggest change until x86-64 came along in 2001-2002 or so.
- Oh man.
I was writing the motor controller code for a new submersible robot my PhD lab was building. We had bought one of the very first compact PCI boards on the market, and it was so new we couldn't find any cPCI motor controller cards, so we bought a different format card and a motherboard that converted between compact PCI bus signals and the signals on the controller boards. The controller boards themselves were based around the LM629, an old but widely used motor controller chip.
To interface with the LM629 you have to write to 8-bit registers that are mapped to memory addresses and then read back the result. The 8-bit part is important, because some of the registers are read or write only, and reading or writing to a register that cannot be read from or written to throws the chip into an error state.
LM629s are dead simple, but my code didn't work. It. Did. Not. Work. The chip kept erroring out. I had no idea why. It's almost trivially easy to issue 8-bit reads and writes to specific memory addresses in C. I had been coding in C since I was fifteen years old. I banged my head against it for two weeks.
Eventually we packed up the entire thing in a shipping crate and flew to Minneapolis, the site of the company that made the cards. They looked at my code. They thought it was fine.
After three days the CEO had pity on us poor grad students and detailed his highly paid digital logic analyst to us for an hour. He carted in a crate of electronics that were probably worth about a million dollars. Hooked everything up. Ran my code.
"You're issuing a sixteen-bit read, which is reading both the correct read-only register and the next adjacent register, which is write-only", he said.
Is showed him in my code where the read in question was very clearly a *CHAR*. 8 bits.
"I dunno," he said - "I can only say what the digital logic analyzer shows, which is that you're issuing a sixteen bit read."
Eventually, we found it. The Intel bridge chip that did the bus conversion had a known bug, which was clearly documented in an 8-point footnote on page 79 of the manual: 8 bit reads were translated to 16 bit reads on the cPCI bus, and then the 8 most significant units were thrown away.
In other words, a hardware bug. One that would only manifest in these very specific circumstances.
We fixed it by taking a razor knife to the bus address lines and shifting them to the right by one, and then taking the least significant line and mapping it all the way over to the left, so that even and odd addresses resolved to completely different memory banks. Thus, reads to odd addresses resolved to addresses way outside those the chip was mapped to, and it never saw them. Adjusted the code to the (new) correct address range. Worked like a charm.
But I feel bad for the next grad student who had to work on that robot. "You are not expected to understand this."
- Book: You Are Not Expected to Understand This: How 26 Lines of Code Changed the World by Torie Bosch [1]
Came across this book randomly on Twitter and picked it up. The book is broken into 26 essays about significant pieces of code (defined vaguely), ranging from the Morris Worm to Pagerank to the popup window and the 1x1 invisible gif and how these shaped the modern tech landscape. Lovely read overall, and really shows how pieces of code you work on today can end up having long lasting impact on how society perceives technology as a whole. Best of all, it's not a heavy read, but offers a lot of concise info that can send you down wormholes of wikipedia.
Paper: Amazon DynamoDB: A Scalable, Predictably Performant, and Fully Managed NoSQL Database Service [2]
Database systems have always been a passion of mine, and the paper from AWS about how DynamoDB works internally is an incredible look into what makes a NoSQL DB platform capable of serving 89 million requests per second _(this is in the intro)_ which is incredible scale. Always good to see how engineering decisions shape products, and it's been interesting to see Dynamo take shape over the last decade _(though I recommend most folks to stay away from it because of it's mad pricing)_
[1]: https://www.goodreads.com/book/show/60254955-you-are-not-exp...
- It's the title of the book, too. *You Are Not Expected to Understand This: How 26 Lines of Code Changed the World." I agree, it's a terrible title, it sounds like a technical book about a single 26-line snippet of code, but it's actually a series of 26 unrelated essays about people & their societal impact, and it's not a technical book at all.
TBH though, it sounds like an interesting book, and probably a pretty small time investment. I might buy it despite its dreadful title.
Related
You Just Don't Understand
10 recommend · 26
You Don't Know JS
88 recommend · 123
Cryptonomicon
324 recommend · 847
On intelligence
114 recommend · 228
You are not a gadget
27 recommend · 60
You're Not Listening
2 recommend · 5
Termination Shock
34 recommend · 149
