Gary Kildall Has a Talk with PC Magazine

My little Christmas gift to you

Dec 25, 2023

I’m a bit of a Kildall fanboy. As such, here is my Christmas gift to you: an interview that PC Mag did with Gary in the summer of 1982. As always, it is very interesting. Enjoy and Merry Christmas.

P.S. Fellow Substacker Al from

Al's Geek Lab Substack

released an in-depth documentary about Kildall on YouTube. He released a longer version without ads on his Substack for his paid subscribers. It is well worth the watch if you want to find out more about Kildall.

CP/M's Creator

An In-depth PC-Exclusive Interview with Software Pioneer Gary Kildall

By David Bunnell Jim Edlin

For a few years in its early adolescence, the microcomputer industry had its own version of Hollywood's Oscar, presented by an awards committee of one, microcomputer publisher (now manufacturer) Adam Osborne, in recognition of each year's most significant contribution to the advancement of the new industry. Recipients of the award included such personal computer luminaries as Apple Computer Corporation’s Chairman Mike Markkula (1979) and VisiCalc program authors Dun Bricklin and Bob Frankston (1980). But the very first person to get the award (1978) was a bearded, young software author working out of a Victorian house in the seaside village of Pacific Grove, California.

Paraphrasing the citation that accompanied the award presenter Osborne told a packed banquet hall, “We had a lot of silly little boxes being sold to enthusiasts and doing nothing. Gary Kildall came along and gave us CP/M, an operating system that allowed those silly little boxes to start doing something useful.”

Four years later, with IBM and other major companies vying for a share of the market, the little boxes no longer seem silly at all. And Gary Kildall no longer works in a Victorian house. Digital Research, Inc. the company he founded, now spills out of a sizable new office complex overlooking Monterey Bay. CP/M, an acronym for Control Program for Microcomputers, is now offered not only for computers with curious and unfamiliar names, but is available and in demand for machines bearing the nameplates Wang, Digital Equipment Corporation, and other computer-industry heavy hitters. Its influence has spread even further. Kildall describes IBM's own PC-DOS, together with operating systems sold by several other companies, as “a CP/M derivative.” Now, in what must be interpreted as another award another of sorts, there is a version of CP/M officially issued under the IBM name and logo, though the disk’s copyright notice credits Digital Research.

The original credit, of course, belongs to Kildall himself, who devised the first CP/M version as an entrepreneurial venture after the semiconductor maker he worked for (Intel, maker of the 8080 and now 8088 processors) told him that his CP/M precursor had no commercial possibilities and that they were not interested in it. Now Digital Research offers several advanced descendants of CP/M, as well as computer languages such as CBASIC and a variety of related “systems software” products. Intriguing new products are hinted at for imminent announcement. Kildall has not retired to his laurels behind an expensive desk in some paneled office, however. He is still a man doing the work he loves—harnessing the intricate inner workings of computers. Moments after the end of the interview that follows we spotted him back in his open-office cubicle, surrounded by three computer screens, intent at the keyboard of one of them.

One spring afternoon, Gary Kildall took a break from his terminals to share with PC some tales and insights about CP/M-86 as it is now offered for the IBM Personal Computer, and to gaze a little into the future. His enthusiasm frequently burst through his laid-back demeanor, erupting into a profusion of colored diagrams on the blackboard behind him.

An Uninitiate’s Glossary

The patois of the master programmer rolls flowingly from Gary Kildall’s tongue. Readers familiar with computer intricacies down at the “bits-'n-bytes” level will follow right along. However, we think all who are interested in PCs can benefit from Kildall's insights. To assist uninitiates we offer this glossary.

Returning FF—A function within the operating system reporting the result of its operation to another part of the program by sending the number "FF," which is 255 (the largest a single-memory cell can hold) written in the base-16 shorthand programmers often use.

Development—Program writing.

Symbol table—One product that prepares a program using assembly language.

Persistence—In video displays, the tendency of an afterimage to remain after the screen has been erased.

Backplane—A section of the system unit into which additional circuit cards can be plugged.

Z-8000, M68K—Microprocessors competitive with Intel's 8086.

Source program—A program in assembly language, which gets translated to an “object program” of numeric instructions the processor understands.

Add immediate 5—A program instruction in 8080 assembly language, ordering that 5 be added to the current number the processor is working on.

Op(eration) codes—Numeric instructions—one for each of the basic operations (such as “add" or “compare™) provided in a particular processor's design.

Registers—The working spaces of a processor chip. Different chips have different assortments of registers with different names.

Flags—Special registers that record particular details of a number, such as whether it is zero or not.

Shifts and rotates—Types of arithmetic operations used on binary numbers,

Data bus—The channel via which components of a computer system exchange information.

Algorithms—Formulas for calculation.

Megahertz—For a microprocessor, how many millions of times per second its internal clock ticks, permitting another step in one of its basic operations.

Bank switching—Exceeding the maximum number of memory cells a processor is designed to use by switching its connection among more than one bank of memory.

PC: Tell us about CP/M-86 and how it compares with PC-DOS.

Kildall: Basically, you know the history of PC-DOS—where it came from, and so forth. It's one of the variety of operating systems we call CP/M lookalikes. It arrived on the scene between CP/M version 1.4 and CP/M 2.2, so it has characteristics of CP/M 1.4 and extensions toward the CP/M 2.2-style file system, but with differences because they were kind of simultaneous in design. There are subtle differences but PC-DOS is fundamentally the same as the 8-bit version of CP/M as far as the user is concerned, and also as far as the program interface. Most of the interface differences between PC-DOS and CP/M are misunderstandings of the CP/M calls by the person who wrote the original PC-DOS implementation, simple things like returning FF rather than 1, things that are of no consequence but just weren’t done specifically the same.

CP/M-86 has been out for about 14 to 15 months. It was designed around CP/M-2. It's exactly the same as CP/M-2 in terms of the function calls, the way the interface appears to the user, and the way the program interface appears to the programmer. The difference is in the extensions you find in the 8088 processor. Number one is memory management; the major extension is being able to partition out and allocate memory, to load multiple programs, for example.

PC: That's a difference between CP/M-86 and the 8080 version of CP/M. How about other differences between CP/M-86 and PC-DOS?

Kildall: CP/M is really a complete development environment; with it you get an editor, an Intel-compatible assembler, and a debugging system—DDT—that has built-in disassembly in the debugger itself. So you can just pick up CP/M-86 and start developing your own high-performance applications. From the beginning, CP/M has always had that flavor to it. It's a base-level operating system that is a complete development system in its own right and doesn't need anything else to support it, though people have gone off and added to it. It's like the IBM PC in that way—an open system. The basic system, when you get it and turn it on, still works to perform basic functions. But some people will go toward BASIC interpreter and others toward Pascal or PL/1.

PC: A lot of people are going to be buying the PC who are not software developers and are not likely to become software developers. Will you or IBM offer a user or “run time” version of CP/M-86 for people who don’t need the assembler, the debugger, and so forth?

Kildall: I don’t know. There aren't any plans for doing that at this point. It's traditional for CP/M to have those tools available and we don't want to change that structure right now. We'd be having all sorts of difficulties with the pricing differences. The basic thing we're trying to do with our initial release of CP/M-86 is to make it as much like the 8-bit world as we can. We feel there are a number of reasons it was successful and that the same thing will be true for 16-bit. We just have to get it out there and see what customer reaction is. We'll go from there and work some things out with IBM.

PC: How do you feel about describing the PC, with its 8088 processor, as a 16-bit machine? After all, you call the operating system CP/M-86.

Kildall: I see a 16-bit machine as one that has more memory. I don’t think of it as anything more than that. Hence the PC qualifies as a 16-bit machine. It satisfies all my needs because I've never been concerned about the speed of an 8-bit processor; they've always been fast enough to do the tasks I want. The only thing I've been concerned about is running out of symbol table space, or just trying to stuff a lot of functionality into a small spot. The 16-bit machine relieves that pressure. You've got it with the PC.

PC: What's your evolution of the PC in general? What do you see as its strong and weak points?

Kildall: I think the product itself looks really good. They've done an excellent job of IBM-style presentation. It looks good, works nicely, and the display is reasonably good though it has a little bit too much persistence for me. One problem is it needs more backplane; you can’t stuff as many boards in as you'd like. And 5 1/4-inch disks are just not enough. This industry already knows that we've evolved past those things. You're talking about a 256K memory system with 160K single-sided drives, and that doesn’t make a whole lot of sense. The 5 1/4-inch hard disk add-on is going to occur with any serious usage of the system. Other than that I don’t think there's anything particularly wrong.

In terms of the marketing, they've taken a very professional approach to set standards toward which the rest of the industry can work. I think we've learned things about the presentation of our materials that we'll use in the rest of our product line. I'm sure the companies that maintain the level of presentation that IBM has provided will be successful with their software products, and those that don‘t—that still have a kind of shabby appearance—will probably be out of business within the next few years.

PC: When was the first time you or somebody at Digital Research knew about IBM's PC project, and what were your thoughts when you learned about it?

Kildall: I can't recall exactly when we found out about it. It's probably been over a year. I get a little reluctant to talk about it, because I don’t know that they're not going to come back and ask, "Why did you say that?” IBM is very careful about what you put out. But we’ve known about it since fairly early in the project.

About my response to it: I was really happy. We've put a lot of effort into 8086 stuff for the last couple of years—made a big investment moving our software in that direction. I was really concerned, probably about the time IBM was first talking about using the 86, that the 86 was not going to make it. Everybody was talking about the Z8000, and the M68K was on the horizon, and I thought, “We're going to have some real troubles here if the 86 doesn't make it. We're going to have a really hard time, because we'll have to go back to old CP/M-80 and hope it supports the development of our next generation of software after this faux pos.” IBM basically decided the 86 was going to make it, that we've got a substantial market there to sell to.

PC: You said CP/M-86 has been out for 15 months. What application software has become available for it, and will that software be immediately usable on the IBM PC?

Kildall: There's quite a bit of stuff out that's translated from the 8-bit world. There's a considerable amount of CBASIC (commercial BASIC) software that can come over immediately. The amount that’s going to be available will be evolutionary.

We've contacted a lot of the software vendors we work with. We've told them we're getting into this and are interested in supporting their downloading and production efforts. We've got maybe 15 or 20 of these that IBM has allowed us to use as test sites; they are doing word-processing systems, general ledger, accounts receivable, and spreadsheets.

Killdall on...

CP/M-86's DOCUMENTATION: We're the only supplier to IBM that has done the whole thing—from creating the document, typesetting and printing it, to delivering it in packaged form. This was something we wanted to do to get the experience— everything down to the little picas.

FUTURE IBM DEVELOPMENTS: We're trying to get our OS to match their releases of hardware and so forth. It's really impossible for me to say anything specifically about more disk space, or facilities in data communication, or whatever, because we're really under their confidentiality agreements on those things and we value that very highly. But I can say we're in step with all the things that will be available on the PC. We're in a very open relationship with IBM. They want our system to be successful on their computer. As a result, they let us know in a timely fashion to be sure that our system supports their features.

IBM SOFTWARE PUBLISHING: I don't think they understand the problem of getting new, independently authored software into production in a useful way. I think they're using a simplistic approach that will probably change when they get some experience. The approach of taking software from employees and giving them a cap of $100,000 on royalties is one that we know from experience won't work.

PC SOFTWARE DISTRIBUTION: I think there is going to be difficulty in trying to stuff a large amount of software through a small funnel. Timing is really critical; the reaction time isn’t fast enough. Nine months to a year to react isn’t fast enough. Alternate marketing channels will develop for software. The most selected or preferred software will end up being in computer stores and on IBM shelves, but not the most innovative software; I think you'll find that elsewhere.

One way we're motivating software translation is with our IBM Displaywriter version of CP/M-86. We're really doing promotion, saying to software vendors, "We're selling bunches of this stuff. It’s a very popular system and we don't have any competition." Once they get things running on the Displaywriter, they can go over to the PC immediately.

We also have a program at test sites called "send-receive." It will go out at reasonable cost to vendors who are interested. "Send" runs on 8080 systems and "receive" runs on the PC or any 8086 system, and there is an RS-232 connection we make according to our specification. The program has a little interface to the user that asks what kind of programs you want to send, where they're coming from, where they go to over here, and then there's automatic retransmission going back and forth. This makes it easy to get 8-bit stuff over to the PC. But it’s going to be an evolutionary thing. Available right away on the PC, I'd say, are probably six or seven popular software packages.

PC: What are some of the complexities involved in translating a program from 8080 to 8086 form?

Kildall: Straight translations at the source program level you can do pretty much mechanically. For example, an 8080 Add immediate 5” instruction turns into an “Add AL 5” on the 8086—a very straightforward translation of the op codes themselves. The complexity in mechanical translation comes from situations such as this: The 8080 instruction DAD H takes the HL register and adds DE to it. For the 8086 the equivalent instruction would be something like ADD DX BX, which is fine, no particular problem. You just say the DX register is the same as HL and BX the same as DE. The problem is that the 8086 instruction has a side effect of setting the zero flag, and the 8080 instruction does not. In mechanical translation you end up doing something like saving the flags, restoring the flags, doing some shifts and rotates, and so forth. These add about five or six extra instructions to get the same semantic effect. There are a lot of sequences in 8080 code that produce very strange sequences in 8086 code; they just don’t map very well because of flag registers and things of that sort. The way we get software over is a thing called XLT-86. It's been out six months or so.

PC: By “better” code do you mean smaller?

Kildall: Twenty percent smaller than if you just took every op code and did a straight translation, saving the registers to preserve semantics.

PC: How does the size of the translated program compare to the 8080 version?

Kildall: If you take an 8080 program, move it over to 86 land and do an XLT-86 translation, you'll find that it is roughly 10 to 20 percent larger. With 16-bit machines it's more difficult to address everything; you get op codes that are a little bit bigger on the average. An interesting phenomenon is that one of the reasons you don't get a tremendous speed increase in the 16-bit world is because you're running more op codes over the data bus.

PC: Is CBASIC also going to be available for the PC?

Kildall: CBASIC and also Pascal MT+. These are both running on the PC right now. They'll be offered simultaneously. Then CIS Cobol. PL/1-86 is a more difficult thing. We've worked on that since last July and it looks like it’s pretty close now. We have a lot of future in that one, especially on the IBM PC. We've seen a lot of interest from people who are getting into the PC through IBM channels—PL/1 users; the biggest community of PL/1 users is IBM itself. But the biggest software vendor languages are CBASIC, number one, and Pascal, number two. These are going to be the basic tools.

PC: Will you introduce any enhancements for CBASIC?

Kildall: Color graphics. We've got an in-house color graphics subroutine about ready that will be made available through our languages. It does direct, display memory operations for high-speed rectangular painting, building objects and circles, things of that sort.

PC: Are your CBASIC color graphics similar to those in Microsoft's Advanced BASIC for the PC?

Kildall: They're similar—the same kind of stuff. But we're not necessarily looking for exact compatibility because the CBASIC community is different from the MBASIC. We had the orientation toward color graphics some time ago, and whether there was IBM or not, it was an important part of our future.

PC: Microsoft's BASIC is very specific to the hardware features of the PC, such as the function keys. Will CBASIC be modified in similar ways?

Kildall: I don't know how product specific it's going to be. Other manufacturers, the Japanese for example, have specific requirements too. Our intent is to be as general as we can with the facilities or functions that we add to CBASIC. As this market grows, there's no doubt we're going to have more machine-specific things coming into the language if the customer demand is great enough. Right now the implementation for the IBM PC will handle all the function keys and that sort of thing. That’s no problem because that's built into the internals of our operating system. For the display, in terms of handling screen management, it comes in a package we're going to be releasing called DM. a display manager. This product has been in the works for probably close to a year: it’s definitely in the final stage, but we haven't announced anything. The display manager is something you can link with CBASIC or Pascal or PL/1 or whatever, and it will handle all the stuff you like todo in terms of getting a fully interactive screen.

One of the things I think is significant about what we're doing is taking functions like the display manager system and really standardizing it as part of the operating system. There's also a thing called AM-86, an access method for high-level data-file interfacing.

PC: On other microcomputers it is possible to run Microsoft BASIC under CP/M. Will it be possible to do so on the PC?

Kildall: Doing something like that is fairly trivial. The differences are relatively easy to take care of through a simple interface. Whether we'll do something like that, whether that would run MBASIC, we don't really know at this point. We would need some specific clients to do that. The intention is not to.

PC: What about the possibility of software emulators that would allow programs for PC-DOS to run under CP/M-86 or vice versa?

Kildall: I'm not really hot for emulators of other systems, basically because then you've got to track someone else's development cycle; they come up with a new release and you've got to scramble. There's been an emulator announced for CP/M-86 that supposedly runs under PC-DOS. I haven't seen the emulator, but I understand the differences between the two systems, and I would be extremely surprised if that emulator in fact emulated CP/M-86. Emulators can get you in a lot of trouble.

PC: What do you think is important in the design of an operating system?

Kildall: When you're designing operating systems or talking about software in general, the successful software seems to be that which fits the resource you're working with very closely. If you have a small memory system, the OS is small. It has functionality that is just what you need and does not have a lot of extra frills or bells and whistles. If you overload the machine, the software will not be successful because it’s going to run ineffectively, and if you don't use all the facilities. someone will come in and use them. During the last decade we've seen the evolution from 256-byte read-only memory, which was the first "operating system" that ran the Intel 4004, up to what we're looking at now in terms of real time systems and networking, data base management, and all sorts of things that are really embedded in the OS itself.

Software design for the 8-bit machine takes limited resource into account. You have a small operating system, typically single-user, a single-stream operating system, and it’s not going to have any overlays. The reason you don't have overlays is you are typically using a floppy disk and they're just not fast enough to do overlays. The result is the OS is small, the application code is large, and that’s why CP/M itself can’t get much larger, because the typical application for an 8-bit machine uses almost all that memory, and that's the real constraint. To go to something like concurrent systems—concurrency is doing background and foreground—you have to do it with bank switching, and that's all nonstandard.

The software design for a 16-bit machine takes additional resources into account. We're talking about 128K of main storage in a minimal system, and often a hard disk. What you want to do is add functionality to the OS—the kind of things people are really going to need: concurrency, multi-access file systems, network communications, and shared code. Our strategy is moving people from the 8-bit world to the 16-bit world: The first step is to take 8-bit CP/M and move them over into 86 CP/M, and add memory management for the megabyte machine and multiple-resident programs. Fundamentally, this is the only difference in the system, so anyone who understands 8-bit CP/M can go into 16-bit CP/M and see the same things.

PC: Where does this strategy lead for the future?

Kildall: Single-user concurrent is the mode of operation we feel is going to be the most important way for the PC and other 16-bit machines to be used. That means you have a terminal attached to your PC and work with multi-ground operations. You might have the word processor in the foreground at a particular time. Behind that you have background applications. They're hidden, but could be brought back up to your active console. Maybe there's a payroll program printing checks on your printer at the same time you are doing your word-processing, and maybe a compile going, a network interface, and possibly some programming down the line.

You have to learn how to use this effectively. When I’m going to develop one of my programs, I can be in the editor, switch over to being in the middle of my debugging so I can find more things that are wrong with my program, go back into the editor and make the changes immediately, then switch back to test some more. What I used to do was go into the debugger, make some changes, maybe make some hand patches, take some handwritten notes, run a little further, then go back into the editor and make all those changes. With concurrency you get that immediate response, go right back into the editor, make the changes, do some more debugging. The result is you get all the fixes in by the time you finish the debugging session.

We're trying to bring the mini- and mainframe software vendors into the 16-bit software world through concurrency.

PC: Besides concurrency, what other changes do you see coming?

Kildall: Since we don't have the same limitations on the size of memory, we're going to get a lot more competition in terms of comprehensive, say, spreadsheet-type applications. We've got this functionality; there's no effective limit on what we can add to that functionality. So the old applications we've seen are going to be vastly improved. Each product is going to be significantly better and probably at close to the same price.

We're going to enter the data communications area—that's going to be a hot item. We're very interested in that; we're going to be announcing our plans for a product fairly soon.

Computer Ads from the Past

Discussion about this post