28

What was the first mainstream development toolchain that provided advanced debugging facilities?

By "mainstream" I mean something that was available on home computers, not mainframes or super-expensive workstations. It also implies that it was commercially available (not custom-developed tools that never escaped the garage of some mad scientist).

My definition of "advanced debugging facilities" includes at least the following features:

  • Setting breakpoints without having to define them explicitly in the source code (e.g. using the STOP statement in the middle of a gwbasic program does not qualify)
  • Running step-by-step at the source code level statements (not having to resort to low-level single-machine-instruction stepping)
  • Dumping the call stack, showing the actual function names from the source code
  • Show values of global and local variables without having to look at the raw memory / CPU registers, and know the ABI specs by heart

Any language qualifies (well, any language that supports function calls, given the requirement on being able to view some call stack).

Improve this question
14
  • 6
    The question is at the same time overly borad and way to narrow, as it implies the use of a high level language as well as stack based function calls and then narrowing down to home computers - devices that could by definition only offer a very limited amount of the requested features. Any answer will be argueable at best.
    – Raffzahn
    Dec 6 '18 at 20:46
  • 17
    Your definition of “advanced debugging” is troublesomely low-level-imperative oriented. (I wouldn't even call that advanced.) The first proper debuggers were arguably Lisp interpreters, of course not with breakpoints and such nonsense but with code-as-data and REPLs.
    – leftaroundabout
    Dec 6 '18 at 22:28
  • 6
    FYI, "PC" is used to distinguish a single-user computer from a time-sharing computer. The Xerox Alto for example was called a personal computer even though it cost $32,000 in 1979 and was used for research.
    – snips-n-snails
    Dec 6 '18 at 23:19
  • 8
    I'm gonna guess fly swatter.
    – jpmc26
    Dec 7 '18 at 0:53
  • 8
    Well, this isn't an answer, because it's way outside your definition of "mainstream". But I have to mention it as the grand-daddy of interactive debuggers. It's DDT, the debugger for the DEC PDP-1, a machine delivered in 1961. The debugger, built maybe in 1962, featured breakpoints, variable display in several formats, and code patching on the fly. It was certainly advanced for its time, and was likely an ancestor of the first debugger that meets your criteria. Wikipedia
    – Walter Mitty
    Dec 7 '18 at 1:18
37

The "Basic Programming" cartridge for the Atari 2600 came out in 1980 and it supports all of those except the first one. It had windows for the program, stack, variables, and output which could individually switched on and off (the cartridge would vertically stack as many enabled windows as would fit, stopping when all enabled windows were shown or it reached the bottom of the screen). Unfortunately, it had to fit in 4K of code space and run on a machine with 128 bytes of RAM (so the program, variables, stack, and output were limited to a total of 64 bytes), but I don't think I've seen anything that sophisticated on any more powerful machines prior to that.

Improve this answer
11
  • LOL. Supercat, that's a great answer. ;) Made my day !
    – Raffzahn
    Dec 6 '18 at 21:17
  • 3
    A very interesting answer in the trivia sense, but falls way short of being a mainstream programming environment.
    – Brian H
    Dec 7 '18 at 1:15
  • 1
    @BrianH: While I agree it's hardly a mainstream programming environment, the inclusion of variable and stack windows suggest that Warren Robinett had some interesting ideas for what a development environment could do, which might have been implemented in more "mainstream" fashion had he been targeting a more powerful computer.
    – supercat
    Dec 7 '18 at 5:59
  • 1
    @BrianH - Seems like it ought to count as "mainstream" to me. Basic was the language of choice on mass-marketed computers back then, and that cartridge was sold in Sears.
    – T.E.D.
    Dec 8 '18 at 22:09
  • 1
    @BrianH: SO answers are expected to be useful to many people in addition to the person asking the original question. In many cases, people interested in wanting to know about the first X to do Y will be interested in when various features were invented. While Robinett's cartridge was a toy, it demonstrates that many concepts found in mainstream debuggers go back a long time.
    – supercat
    Dec 10 '18 at 8:14
15

The earliest innovator I know of was Manx. Manx made 'C' programming environments for early, low-cost computers like Apple ][, CP/M-80, MS-DOS, and Motorola 68000.

Manx Aztec C v1.06 had symbolic (source code) debugging support when released in early 1984. Manx provided a utility "SIDSYM", which was used along with their linker's ability to generate symbol tables, to feed source code and symbols into SID. SID was a debugger from Digital Research for CP/M-80 that supported symbol tables. The Aztec C data sheet from 1983 mentions this feature.

The system above was still pretty primitive by modern standards. The "killer feature" was a source-code level debugger that hid most of the machine code details and allowed you to interact with your 'C' code as written, and access run-time variables easily, and set conditional and regular breakpoints with ease. This is the basic user experience we all expect today in Visual Studio, etc.

Manx continued to evolve the source debugging feature. By 1988, their 'C' compiler for the Amiga included a fully visual GUI source debugger that was probably the most advanced for any low-cost PC or home computer at the time. The MS-DOS versions of Aztec 'C' for the 8086 also supported source debugging at the same time, but with a less advanced UI. This feature is described in the manual available online. This was before Borland first shipped their initial version of Turbo Debugger for MS-DOS, as an add-on product to their compilers. Other 3rd parties also made symbolic debuggers for Turbo Pascal, but none that I know of offered as advanced a solution as Manx Aztec C at the time.

Needless to say, Source-level debugging was a "killer feature" for low-cost development environments by 1989. It was not long after that the major players like Borland and Microsoft would catch up and begin offering compilers with IDE's and integrated source debugging as we know today.

You can download Manx Aztec C for various retro computers from the Aztec Museum.

Improve this answer
2
  • You seem to be praising Aztec C for something SID actually did - Aztec C only provided the input for SID.
    – tofro
    Dec 8 '18 at 23:49
  • @tofro Aztec C worked with SID in 1983. By 1988, they included sdb, an advanced source debugger for the time.
    – Brian H
    Dec 9 '18 at 15:08
12

This is less of a definitive answer than a musing about some seemingly underlying assumptions within the question. For the question itself Supercat has already given a near perfect answer. While it is of the typical kind where everyone know it's wrong, it does tick all boxes. I seriously would love to give it double points :)

Different Computer Classes

The most obvious issue with the question may be that it separates different 'classes' of computers - and more important implies important advancements made by them in prior. While it is true, that mainframes implemented many solutions first, they where still tied to their repertoire of tools - like command line operation on terminals in next to all cases. And even within the mainframe world solutions weren't developed for the fun of it, but when needed. Much like with minis and micros in parallel or later.

For example the AID facility of BS2000 (a /370ish OS) did already support quite complex interactive debugging in the early 80s. But all based on very cryptic command line arguments.

Need for more comfortable (I would prefer that term over 'advanced, which is more of a marketing blurb) debuggers grew out for one of more capable systems and more complex software, but more important due changes in software development. This includes especially the need to dive into large chunks of code generated by less then well known tools (compilers), imported from libraries or worst of all, inherited form prior developers.

This development happened independent of machine type or 'class'.

Source Level Debugging

Already early microcomputer systems offered basic debuggers that did go past all hex handling of Hex-Kits. For example the original Apple II Monitor included convenient single-stepping and breakpoints with disassembling the instructions. And with the introduction of disk drives and Assemblers many additional tools came to hand, including source level debuggers. That's the 1978..1980 time frame. Eventually with the ORCA system as a first plateau supporting very convenient Assembly as well as Pascal and C - noteworthy here, that is wasn't until the mid 1980s that C became a professional supported choice on Apple II (or similar) systems.

In general it was not only missing need, but more so missing capabilities of the systems in use that prevented the use of more comfortable features. To access join binary and source code the later needed to be at least indexed, a feature the quite limited memory of these systems could, if at all, only support for extreme small programs. Even more so if the source code had to be displayed. Impossible without multiple disk drives.

Beside Assembly (and the all omnipotent BASIC) PASCAL was the only other choice. Here the UCSD system was eventually the best known - and it made a great case how to provide high level support on small machines. The p-code did include many references to the source/module structure already by default, and due its module structure parts of the system could be swapped in on demand.

It wasn't until affordable machines by default had a RAM size of 512 KiB or more and hard drives that more comfortable features as requests became possible for most programming environments.

Workstations are Anything But PCs

When comparing machines, that have been sold as 'workstations' at their time, with other available it becomes clear, that there is no basic difference to other machines of the same time -- except they usually represent an upper end configuration.

A Sinclair QL of 1984 used a 7.5 MHz 68008 with 128 KiB RAM and micro-drives, while a SUN 2/50 of the same year had a 10 MHz 68010 with 8 MiB RAM and (at least) one HD. The same point can be made for any other computer sold as Workstation - not to mention todays Gamer PCs that outclass what many manufacturers sell as workstation :)

Home Computers are Computers at Home

While this sounds nice at first, it's a classic post-hoc fallacy. After all, that would make any computer someone may have at home a "home computer". Of course including any mainframe, mini or workstation running zOS or Unix. It's obvious this won't work as a portable classification - most definitely as porting the same computer into an office would right away turn it into an office computer - wouldn't it?

The location a computer is set up can not retroactive define a class.

Conclusion

The question contains a lot on unnecessary constrictions and implied assumptions that are neither clear nor helpful at all, and at the same time an unclear definition what environment exactly is asked for.

It may be useful to drop these restrictions and clarify what kind of functions and their representation is asked for.

Improve this answer
5
  • 1
    We have a feature supporting upvoting twice. It's called a bounty. You might've heard of it! We've only had three bounties awarded so far (iirc) and four set, and none set on somebody else's question. You'd be the first.
    – wizzwizz4 ♦
    Dec 7 '18 at 7:22
  • 1
    Thanks. And I'd be really interested in how the development environment of Smalltalk and Lisp looked in say 1980...
    – Martin Schröder
    Dec 7 '18 at 9:29
  • 2
    @MartinSchröder - uniquely, Smalltalk standardised its development environment at the same time as standardising the language itself, so any modern (unextended) implementation of Smalltalk-80 should provide a development experience that is very similar to the original 1980 implementation. This means that if you download either GNU Smalltalk or Squeak and play with them, other than the extended GUI class frameworks, what you're using is pretty similar to what existed in 1980. Which is to say, a very high quality polished environment, albeit not one that was available on a "home" computer.
    – Jules
    Dec 7 '18 at 20:17
  • 1
    The "other" answer also assumes that everyone believes "advanced" means "has lots more goo, much of which gets in the way of people who want a lot less goo." Or put another way, I did very good debugging in some pretty "extremely feature poor" debuggers and I was very happy with them. I didn't realize that I absolutely had to have source-level debugging ... which often worked very badly because the optimizer had moved my code all over the damned place. I was perfectly content to look at machine instructions. No, really. Much better than broken source-code debugging.
    – Julie in Austin
    Dec 7 '18 at 20:26
  • @JulieinAustin: I remember tracking down a problem where source-level debugging was quite useless. The MPW compiler could register-cache automatic objects as well as constants; the symbolic debug information annotated the former but not the latter. When incorrect function prologue code corrupted a register that held a cached constant, the debugger would show me the address of someArray when I put a breakpoint on a call someFunction(someArray), but what the function would actually receive was a corrupt register-cached copy of that array address. Oops.
    – supercat
    Feb 1 '19 at 19:11
10

Microsoft Codeview shipped in 1985 and has most of the features you're asking about (its been a while so I can't be certain it has everything e.g. call stack walking), when I was doing Turbo C support for Borland in 87/88 support for it was possibly the most requested feature.

You could do source level stepping with Turbo C & symdeb but it wasn't as nice. Version 2 of Turbo C had a debugger (shipped late '88?) which used the 386 hardware support.

Both of these had dual monitor support which was nice.

Improve this answer
7
  • What 386 features did the Turbo C 2 debugger use? I remember debugging on my 8086 without missing anything ;-). The dual monitor support was definitely very useful.
    – Stephen Kitt
    Dec 7 '18 at 12:05
  • 3
    More memory (as the debugger uses XMS), hardware breakpoints on read / write memory/IO.
    – PeterI
    Dec 7 '18 at 12:40
  • 1
    Ah, now I get it, I thought you were talking about the IDE’s built-in debugger, not Turbo Debugger.
    – Stephen Kitt
    Dec 7 '18 at 13:45
  • 1
    My Borland Turbo C 2.0 Reference Guide has a copyright year of 1988.
    – user
    Dec 8 '18 at 14:17
  • 1
    @wizzwizz4 If the Reference Guide is copyrighted 1988, that's a pretty strong corroboration for the "shipped late '88?" in the answer. At least I would expect the two to largely coincide.
    – user
    Dec 8 '18 at 16:11
10

I'm including this answer in response to a couple of suggestions, although it does not meet some of the criteria laid out in the question. DDT for the DEC PDP-1 has to be recalled as probably the very first interactive debugger, and most interactive debuggers that came later were indirectly inspired by DDT. (see DDT Writeup).

DDT was built in late 1961 or early 1962 at MIT shortly after the arrival of the PDP-1 (serial number two). The author was Alan Kotok, who later went on to be the principal engineer of the DEC PDP-10, one of the main timesharing systems before the microcomputer made a single user machine economical.

DDT allowed the user to set a breakpoint, examine variables in several convenient formats, alter variables, disassemble instructions, and patch code. This allowed the human to make efficient use of the very scarce machine time available. Some of the features mentioned in the question are lacking, but DDT was very advanced for its timeframe. A more advanced version of DDT was later built for the PDP-6 and the PDP-10. The VAX debugger was probably inspired by these.

The PDP-1 (wikipedia) was probably the first commercial interactive computer intended as such. Even though only 53 were built, it had an enormous impact on later industries like video gaming (see Spacewar), Word Processing (see Expensive Typewriter), and even computer hacking (see Hackaday).

Steve Russell, author of Spacewar, later introduced a couple of prep school kids (Paul Allen and Bill Gates) to the PDP-10.

The PDP-1 computer predates the microchip, which made mainstream computing viable. But mainstream computers of the 1970s and beyond owe an enormous debt to the PDP-1. Without it, mainstream computing might have taken a very different path.

Improve this answer
6
  • 1
    Woah. From the "expensive typewriter" manual, in chapter "Transfer commands": "N (Nightmare): Transfers control to the Nightmare version of the assembler CERTAINLY, which gets the source program directly from ET's text buffer. The resulting binary program is placed on drum field 1, the program is brought into the users core memory, ID is provided with the symbol table and control is returned to the ID, where a P (proceed) command will start the newly assembled program running.". I don't quite uderstand how all of this worked, but the guys surely had fun naming the programs and commands.
    – dim
    Dec 7 '18 at 15:11
  • I didn't know about Expensive typewriter but the concept of having a "control mode" and a "text mode" sure reminds me a lot the vi editor (which came out only a few years later).
    – ChatterOne
    Dec 7 '18 at 15:23
  • I think the name "expensive typewriter" has been used more than once.
    – Walter Mitty
    Dec 7 '18 at 18:58
  • TECO had a text mode that was terminated by the ESC character. Certain commands like Insert and Search initiated text ode.
    – Walter Mitty
    Dec 10 '18 at 20:35
  • 1
    DDT for the PDP-1 was based on FLIT for the TX-0 in 1957, which may have been the first interactive symbolic debugger. From the 1966 paper "On-line debugging techniques: a survey" (dl.acm.org/doi/10.1145/1464291.1464295), "With FLIT, for the first time, it was possible for the user to examine and modify his program in terms of the symbols used in his source program ... FLIT introduced what is perhaps the central notion of interactive debugging, that of a user-controlled breakpoint."
    – Jonathan Stray
    Dec 10 '21 at 18:29
7

THINK Pascal had an integrated debugger that meets all your criteria. You could mark stop points in the editor and then debug your compiled code using them. The debugger supported stepping, a meaningful call stack display, and a good list of the variables as structured typed information.

Improve this answer
2
  • I think Manx Aztec C had these features much earlier.
    – Brian H
    Dec 7 '18 at 3:12
  • 1
    If we're looking for the earliest usage, it would be from when it was called Lightspeed Pascal; I think it was introduced in 1986. The name was changed at some point to THINK Pascal. (I'm not sure if the name change was when Symantec bought it from THINK Technologies or if the name was changed earlier.)
    – Mitchell Spector
    Dec 8 '18 at 21:31
6

The extremely popular BBC Micro (1981-1986, still in retro use today) had an exceptionally powerful debugger, "Beebmon" by Watford Electronics, capable of breakpoints, IRQ trapping, code stepping, and so on. From a summary:

BEEBMON

A ROM based machine code monitor for BBC Micro. It enables machine code programs to be debugged and altered easily and quickly. Being a ROM, its commands are always readily available and occupy no user memory. Appears to take no base page and only one page of relocatable workspace (256 bytes) and no more anywhere in RAM. Beebmon can do more than any other machine code monitors currently on the market. The special features include facilities like: TABULATE, MODIFY, FILL, COPY, COMPARE, SEARCH (HEX & ASCII) CHECKSUM, DISASSEMBLE, RE-LOCATE and, by emulating the 6502 processor, SINGLE STEP, BREAK POINTS ON READ/WRITE/EXECUTE OF LOCATION. Also BREAKPOINTS ON A, X & Y REGISTERS are provided . HAS WINDOWS INTO MEMORY & TEST WINDOWS. All this and more...

I used this to trace IRQ handling in the OS and other ROMs, and to reimplement disk and keyboard handlers for software which required modified handling. I think it came out very early on, around 1982, and certainly by 1983 (according to the source).

Description source: Watford Electronics flier, 1983, on 4corn.co.uk

Improve this answer
1

CP/M, first released in 1974 had a utility called DDT (dynamic debugging tool) which offers the features you list, but in the context of assembly language. It's a bit of a stretch to say you could examine the call stack, you could examine the stack.

However, given that you talked about "mainstream" and microcomputers, I think it qualifies because back in the eight bit days, if you wanted to do anything serious on a micro, you programmed in assembler.

Improve this answer
1
0

The Nascom computers (released 1977 and 1979) came with a timed circuit on an output port that would allow for a POP AF; RETN sequence and one more opcode fetch before triggering an NMI. The system ROM used this for single-step support through assembly code. It was also possible to set a single breakpoint in RAM (it would use one of the 8 zero-page call opcodes) and the original opcode would get restored no matter how you returned to the operating system (there was a denial-of-service program circulated which could not be terminated by a hard reset since that "restored" an "original opcode" into the return stack of the hard reset routine, letting it return to the denial-of-service code instead).

A later released debug extension costing 1kB of EPROM space offered more extensive breakpoint and diagnostic utility (including viewing the return stack though not in the form of a traceback since stack frame organisation was unknown) and could interoperate with a disassembler implemented in another 3kB for mnemonic debugging. The usual way of filling the 8kB EPROM capacity of the Nascom II consisted in putting a 4kB editor/assembler in the rest.

At any rate, this hardware-assisted facility for single-command execution on a Z80 CPU was a precursor of trace facilities built into much later microprocessors.

However, debugging was not symbolic.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.