Be Newsletters - Volume 2: 1997
Usually during the course of a day, I encounter something that is bothersome or just not quite right. The radio in my car is too close to the cupholder, so whenever I put down my coffee, the station gets switched from Howard Stern to Rush Limbaugh. Loading a new bottle into the office water cooler inevitably spills a few drops on the carpet. The sandwich guy asks my views of mustard versus mayonnaise despite having heard the full details just seconds earlier.
Porting operating systems to different hardware architectures is no different. Every system from the Rockwell AIM-65 through the Power Computing PowerTower Pro dual 225 MHz 604e has quirks that must be dealt with. Perhaps someday we'll design a system that's perfect, fast, reliable, and easy to write software for. If whoever builds it needs some unsolicited advice, I have a list...
Put in a software-readable version number. For chips, put in a read-only register. For circuit boards, dedicate a few I/O bits somewhere and put in some pull-up/pull-down resistors to make a unique identification possible. For I/O devices, put it wherever it's convenient. Whenever a change is made, even one that doesn't affect the operation of the software, change the version. Someday you'll be glad you did, be it for manufacturing test, field service, consumer recall, hardware debug, user interface, or geek fascination with frivolous detail.
Avoid write-only bits in registers—let software read back what was written earlier. Avoid bits that mean different things when read and written—chew up a little decode space instead and put them in separate registers.
Design registers that can have individual bits modified in a single operation. This really helps when there's more than one bus master mucking about the system, in that register updates don't need to be protected with a software semaphore lock. My favorite example is the 6522 VIA registers—the most significant bit controls whether you're setting or clearing, and the rest of the bits have a one wherever a bit is to be modified and a zero wherever a bit is to remain unchanged.
Document what you design, preferably in a way that someone besides you can understand. Describe not only what it is, but also what it's for. Anyone who's taken a tour through a data book for a modern VGA graphics controller can appreciate this. Better yet, include some real (that is, actually compiled, run, and debugged) source code that uses your design. Keep the documentation available even after you stop selling the part. Make the documentation easy to get—and free.
Avoid timing dependencies. Any synchronous protocol or continuous input data stream is an exception of course, but even there you can help by providing a bit of buffering in your hardware. Putting a 5-million transistor 225 MHz screamer into an interrupts-disabled spin loop waiting for a few microseconds to pass before writing to the floppy controller again due to some empirically observed resistance to being written faster is not the best use of available MIPS.
Make physical RAM contiguous. It's just easier that way.
For multiprocessor systems, it's nice to be able to direct I/O interrupts to different processors to distribute the load. Also, it's nice to be able to turn off all I/O interrupts to all processors in a single operation and to turn them back on later, while still allowing interprocessor interrupts.
For CPUs, it would be nice to separate I/O interrupts from interprocessor interrupts; having a different pin, a different interrupt vector, and a different interrupt enable is ideal.
Resources that are duplicated across different parts of the system should have support for synchronizing their state. For instance, the PowerPC has a time base register and a pin for enabling it. Without that pin (or without any means of actually controlling that pin), it's impossible to ensure the time base register has the same value on all processors.
For debugging, provide a means of doing a nonmaskable interrupt to all processors, preferably from an optional switch, and also from a software-accessible register. If this is a recoverable interrupt in the CPU, all the better. This will make OS designers everywhere think of you fondly every time the system locks up and they can push a button and get to a kernel debugger.
Noncoherent caches aren't a good idea. A simple OS may be able to deal with caches that aren't coherent with DMA accesses, but anything beyond DOS or the maces will have major conniptions.
Plan for bugs. Leave a couple of I/O pins around to let you control a PAL later, so you can do a quick turn on your design to fix the bug in the new improved gizmo that replaces the no-longer-manufactured old gizmo.
Let the OS designer have one bit of visible I/O somewhere. A place for a two-pin header where an LED can be hooked up will do. Alternatively, provide a place to hook up a logic analyzer.
Expansion buses should be self configuring (for example, NuBus) or software configurable (for example, PCI). For an example of how not to do this, see ISA, SCSI, or IDE.
Make the case easy to open. See the Mac IIci for an example.
Put upgradable stuff where you can get at it. For an example of how not to do this, try adding RAM to a Power Macintosh 8500.
Use the circuit board silk-screen for user documentation. If you've made the mistake of requiring jumpers, describe the jumper options right on the board.
If you must use jumpers, put an extra one or two on unused pins. Not everyone lives ten minutes from Fry's Electronics.
Use the circuit board silk-screen to make it easier to debug or probe. Label the chips with real names instead of "U24." Then tag every tenth pin with its pin number. This helps anyone poking around with a scope probe, and besides, its cool to personalize what that black plastic behemoth is doing millions of times a second. While you're at it, label some test points for clocks and interesting logic lines.
If you must use screws, use the same kind everywhere. If they must be different lengths, at least make them the same thread. Make sure your design holds together if any one given screw is missing, because that screw always falls off the desk and takes a four-hour vacation somewhere.
Make it quiet. Otherwise, you can't use it while your spouse is sleeping.
Avoid sharp edges. I hate bleeding on my motherboard.
Connectors should be keyed. If not, they WILL be plugged in backwards. Lay out pins in connectors so that when they're plugged in backwards, smoke doesn't appear.
Why is it that whenever I plug in the little twisted wire power LED, it's always the wrong polarity? Label the pins, preferably with the wire color that they're supposed to take. Alternatively, given the vagaries of wire color selection by LED vendors, label the pins minus and plus, and I'll just assume that the black wire goes to minus.
If it's different, use a different connector. I'm sure many parallel printers have been plugged into the SCSI ports on the back of Macintoshes everywhere. And in ancient times, 9-pin monitor cables were plugged into serial ports.
If it's different, make it obvious that it's different. Can you tell the difference between a 3.5-volt DIMM and a 5- volt DIMM? Why aren't they labeled? For that matter, why aren't SIMMs and DIMMs labeled in the first place? Not everyone knows how to read DRAM part numbers.
Hardware designers who read this article may react defensively and start writing their own list about operating system design. They're right to do so—we're by no means perfect. If you need to get something off your chest, send it to herold@be.com.
A minor update to last week's newsletter—the DR9 system_time()
function will return the number of microseconds since boot, not the
number since January 1, 1970. We decided that it's important to have a
monotonically increasing system_time() value even across changes to the
system's real time clock. You can calculate the number of microseconds
since January 1, 1970, by using the ANSI C time() function and the
boot_time field in the system_info structure.
Believe it or don't, I'm actually writing this article under DR9. Hiroshi's StyledEdit is on my desktop along with cool DriveSetup, Disks, and Trash icons. "NuBar" hangs at the top, keeping track of applications and windows, Pavel's DigitalClock sticks seconds in the recessed right corner.
Over all, Doctor Nine is looking pretty good. (They sure added a lot of stuff.) The QA Queen has called this the "Release from Hell." When the QA Queen speaks, she speaks the Truth. Weeks went by while the file system collapsed beneath me. I'd step into Dominic's doorway, my figure reflected in the window in the wall. With a glance and a toss of his hair, he'd turn to me and inquire, "Spinning forever?" But hey, what's a file system if you can't start 8 to 10 cp's of tar files, xvf them as they arrive in a new directory, then gzip the lot and chop it into 1k pieces. Hey dude, double indirect this. And isn't everyone going to be running the mvaawhile shell script, renaming said folder to aa, bb, cc, dd, ee, ff, on to zz and back to aa to start all over?
Swap space is your friend.
One by one the big bugs got squashed, Dominic and I became virtual lovers, but then the new file system stabilized, and we started seeing other people.
See, I'm not happy unless something's breaking.
Robert Chinn, the King of the Underpinnings, spearheaded the transformation of the top-secret BeLabs II, which now sports new supports. Baby Macs and Daddy Macs are backed by BeBoxes with cereal for breakfast, lunch, and dinner. Me? How could I live without post-its?
It's pretty much round-the-clock here. We know you want it, our software hardens your hardware and all. We're thinking ahead. Big files, lots of RAM, cheap hard drives, flaky video cards, network throughput, partitions. You wanna build servers, games, interactive cross-pollinational subfactories for new world estates. You want to Be in charge, you don't want to wait. We will feed your need.
This is a Revolution, dammit.
We're not building the OK-OS.
Tomorrow morning (Monday) I become the Build King, and with a keystroke sequence built by Ming (whose name, curiously, is King with an M). I'll install and test the BeOS on every family of PowerPC-based machine we support. Then my Queen will ask for a report. Then I'll get lunch. Then I'll show Cyril the VM deadlock thing, show Steve and Cyril the dropping_notification thing, try to find the end of the benoit_rainbow on this mouse_down thing, and the funny thing is, they know what I'm talking about and you don't.
:)
As Bob Herold pointed out once, it's a strange and secret language we speak here at Be, but keep your fingers crossed, don't settle for less than what you love, raise your hands and lower your fingers and believe there is a team of brilliant engineers slaving tonight to bring you what you need.
The BeOS, a fresh, modern, carbon-fiber Operating System.
We'll talk again halfway to Macworld.
DR9, DR9, DR9!!!
Let's see. How easy or difficult is it going to be to move to DR9? Any time I mention C++ nasties, I get some sort of response from someone. Last week was no exception. One response to my statements about the introduction of const was that things will be safer, another response was a developer telling be how annoying const is and that they finally learned how to cast it away. Also with the virtual destructor business, on the one hand making virtual destructors makes things safer, on the other, it bloats class frameworks. The answer is, get yourself one of those "Effective C++" books or the "C++ FAQs" book. These books are invaluable to the beginning and very experienced C++ developer. If you read a snippet every day, you'll find yourself saying "Oh, that's why that happens." DR9 shows much improvement in safety and stability. A lot of this has to do with much tighter C++ coding practices. If you're coming from DR8, you'll notice new compiler warnings where your code previously didn't generate any.
BView::KeyDown(const char *bytes, int32keyCode)
If you overrode this in DR8, you probably had
MyView::KeyDown(longkeyCode)
In DR9 this will generate a warning. Something about you overriding something similar. This isn't strictly an error, but your KeyDown will not get called! This is one of those "subtle" differences. After you ignore our release notes for DR9, and just try to compile your code, you'll come back here and read these words:
Compiler warnings are your friends and will make for safer hex. The more you fix, the safer your code will be, and you won't be staring at a debugger window more than your running application.
DR9, DR9, DR9...
Ah, a stable release. We've got to have apps, we've got to have apps! Ah, there's Fred Fish and his GNU efforts. Boy oh boy, look at all those little command-line tools. Well, at least we have autoconf and m4. Now it's much easier to recompile the rest of that world. Dominic is a POSIX fool, and he did quite a lot to make sure the file system was quite POSIX looking. There are other additions to the OS that make it even more POSIX compatible, so it would behoove you to go out and get the "POSIX Programmer's Guide" if you're so inclined. This thick purple book from O'Reilly & Associates should give you all the information you want to know about POSIX. We aren't a UNIX system, but it sure doesn't hurt to implement the various POSIX calls so that it's easier for people to write apps.
I want to compile! I need the IDE! Oh well, I'll use vim for now. Ahh, the IDE has shown up, and it does Java! Oh boy, Oh boy.
Let's see, first I'll do Tcl, then I'll do another rev of the imaging thing:
ftp://ftp.be.com/pub/contrib/gfx/lib/imaging_dr9.tgz
This one does fast scaling as well as the bilinear stuff. And then another rev of the yags library to add the spline support:
ftp://ftp.be.com/pub/contrib/gfx/lib/yags_dr9.tgz
And how about that zip and unzip thing. And what about a new tvtuner? Say, what's that FireWire board doing in here? Oh, wait a minute, I hear something... Yasmin sounds like she's waking up... Just one more compile, just one more compile! OK, OK, we'll go to the store and buy your birthday cake, sorry I forgot. Here's a sandbox to boot. All right, we'll give you a party next weekend, now can I port some more?
Oh yeah, sister-in-law's engagement party, relatives visiting, water the grass, put the pool cover on.
I like this DR9 thing. I want to port that treeview code. Oh, look, there's a hierarchical view widget included with DR9? Well, how about some sound code.
ftp://ftp.be.com/pub/Samples/sndutil_dr9.tgz
And what about that scrappy little MPEG-1 decoder? Can't you make it a little bit more encapsulated so that multiple MPEGs can be played at once? And why don't you throw a real interface on it while you're at it.
ftp://ftp.be.com/pub/Samples/mpeg_play_dr9.tgz
OK, it's 2:30 am Monday, time to go to bed, you can play some more
tomorrow. With features like a real working fork() instead of spoon(),
and a system() call that returns the proper values, DR9 is shaping up to
be quite the solid citizen. If you play safe and follow the rules, not
only will your apps be wonderful and wise, but they'll probably run
faster to boot. The Developer Conference is quickly approaching, and I'm
quite beside myself with anticipation. Between now and then, we have a
belated birthday party, some major application porting, and some demo
apps to write. This is definitely a must-attend event. See you at the
front.
Windows are passeé, said an Apple scientist about twelve years ago. The Mac was painfully taking flight right after the Lisa "Spruce Goose." I thought reports of the demise of windows were a tad premature. I even thought it was foolish.
I wasn't buying the story that the Mac (or PC) desktop had to mimic my desk, but I thought windows were a really nice way to separate contexts and to move them around. Windows, I thought, fulfilled a durable need and, like the wheel, once invented were there to stay. I still believe this—and more, as we say in my adopted country. What we could call the classical way of UI evolution seems to have entered the era of diminishing returns. As I type this, I remember the original MacWrite with its simple menu bar. I use 1992 vintage Word 5.1a (on a PPC machine running both BeOS and Mac software); Word 6 is frowned upon at Be, unless used to demonstrate Virtual Mac performance under stress. On Word 5.1, much more screen area is taken by tool and menu bars than in the original Mac word processors. It gets worse on Word 6 and, on Windows Office 97, one can end up with a debauchery of tool bars and palettes. In fairness, you can go in and remove enough tool bars to go back to 94-95 levels. In the industry, the joke is, by the year 2000, the screen area left for the actual meat of the document will be the size of a first class $1.50 e-mail stamp. Joke or not, there is an uneasiness about UI paralleling bloatware on the hard drive.
There is hope. Netscape is demonstrating versions of its future client, Constellation, parts of which will soon surface in Netcaster. Sliding panes and tiles smoothly slide in and out of view, allowing better use of screen and desktop space and reducing the anxiety and confusion arising from poorly presented access to huge volumes of local or remote information. Windows, as units of context, are still present, but in a streamlined, less obtrusive form. To a more modest extent, this is the case with Explorer 4 in its platform preview incarnation. The UI can be set to a classical Windows 95/NT style, or it can deviate from it in varying degrees, including going to a one-click Web-style document opening. On the desktop, "raw" borderless Web documents can be exposed, live or static. And they can be dragged around, under the rest of the desktop, without annoyingly jumping on top. Still at an early stage, parents strongly cautioned, but really a more promising UI exploration than Bob.
The more interesting UI developments come from smaller, more creative players. MetaTools, for instance. In products such as Goo, Kai Power Tools, and Bryce, they show how windows as we knew them can vanish, how mouse gliding can cause tools to appear and disappear, drawers to open and close, how the use of translucent objects effectively reduces mental clutter. Their next product, Soap, for cleaning digital or scanned photos, offers such nice UI innovations for users who don't need Photoshop. For the musically inclined, Eric Wenger, the author of Bryce, has also written synthesis software with similarly innovative and soon-to-be-classical UI tools.
On this topic, I have two hopes. One is I'll get mail pointing to all the products I obviously should have looked at long ago. The other is that our new platform will be seen as a fertile field for the development of the next generation of innovative UI elements.
