lindsay@MATHOM.GANDALF.CS.CMU.EDU (Donald Lindsay) (06/12/90)
There's a nifty new wrinkle in the new Motorola DSP, the 96002. It contains what Motorola refers to as an on-chip emulator. The "OnCE" has its own dedicated serial interface, and accepts commands to set breakpoints, report on internal values, and so on. This is, of course, the logical end of a long trend. Once, control points were brought out to a panel - like the B6700, which had a lighted push button for every flip flop in the CPU. Later, control points were brought out to a minicomputer - like the PDP 11/40 inside each DecSystem 20. And now, the control points are brought to a remotely-controlled part of the same chip. From what little I know, the OnCE seems fairly powerful: - break on data address. - trace forward N instructions. - capture last five instructions, and current pipeline state. It might be interesting to discuss what else it should do: perhaps keep the last few branch-from addresses, which I believe the National '16 did. Hardware people go for this stuff, of course. Software people doing simple embedded applications should agree. I submit that a "big" debugger, with system-related features such as file access, should never be cast in hardware. But, perhaps a "big" debugger could profit from the existance of the "hard" debugger. Hmmm; how? Maybe only from privileged code such as the kernel debugger? The people doing the Parasight debugger at Encore claimed that they got better performance by not using ANY hardware features, except whatever cache support it took to have writable code spaces. For instance, they did breakpoints by zapping branch instructions, not traps, into the target code. The claim was that they could completely avoid interrupts and kernel entries, and that this was always a speed win. I guess I agree, as long as the users are "above" i860-ish issues such as pipeline configuration. -- Don D.C.Lindsay leaving CMU .. make me an offer!
jbuck@galileo.berkeley.edu (Joe Buck) (06/13/90)
In article <9598@pt.cs.cmu.edu>, lindsay@MATHOM.GANDALF.CS.CMU.EDU (Donald Lindsay) writes: |> There's a nifty new wrinkle in the new Motorola DSP, the 96002. |> It contains what Motorola refers to as an on-chip emulator. The |> "OnCE" has its own dedicated serial interface, and accepts commands |> to set breakpoints, report on internal values, and so on. This is not new. Motorola's biggest competition for the 96002 is TI's TMS320C30 DSP chip, which has been out for a while and already has this feature. I've used it extensively. It's nice that it exists: you can provide a connector to the chip in an embedded system and tell what's going on -- but it's inferior to a real emulator, since you can only set breakpoints based on instruction execution, you can't trace the data busses (I'm refering to the C30, perhaps Motorola has done a better job). -- Joe Buck jbuck@ohm.berkeley.edu {uunet,ucbvax}!ohm.berkeley.edu!jbuck
wailes@ecn.purdue.edu (Tom S Wailes) (06/13/90)
In article <9598@pt.cs.cmu.edu>, lindsay@MATHOM.GANDALF.CS.CMU.EDU (Donald Lindsay) writes: > > There's a nifty new wrinkle in the new Motorola DSP, the 96002. > > It contains what Motorola refers to as an on-chip emulator. The > "OnCE" has its own dedicated serial interface, and accepts commands > to set breakpoints, report on internal values, and so on. > [ stuff deletede ] > > It might be interesting to discuss what else it should do: perhaps > keep the last few branch-from addresses, which I believe the National > '16 did. > > -- > Don D.C.Lindsay leaving CMU .. make me an offer! Does any present microprocessor allow the instruction fetch to be disabled? For instance, imagine a multiprocessor machine made of many microcomputers that could be switched from normal mode to SIMD mode by defeating the normal instruction fetch and allowing the direct placement of the instruction word on the address lines. This would allow a very quick MIMD to SIMD switch of processor computation. Thus an algorithm that was best modeled using both MIMD and SIMD modes (in different areas of the code) could be switched effectively. Has any present microprocessor maker allowed such a "test mode?" Tom Wailes wailes@en.ecn.purdue.edu
tim@proton.amd.com (Tim Olson) (06/14/90)
In article <1990Jun13.152910.22061@ecn.purdue.edu> wailes@ecn.purdue.edu (Tom S Wailes) writes: | Does any present microprocessor allow the instruction fetch to be | disabled? For instance, imagine a multiprocessor machine made of many | microcomputers that could be switched from normal mode to SIMD mode by | defeating the normal instruction fetch and allowing the direct placement | of the instruction word on the address lines. This would allow a very | quick MIMD to SIMD switch of processor computation. Thus an algorithm | that was best modeled using both MIMD and SIMD modes (in different areas | of the code) could be switched effectively. Has any present microprocessor | maker allowed such a "test mode?" The Am29000 has an asynchronous control interface that is normally used by hardware emulators and debuggers; it controls transitions between RUN, HALT, SINGLE-STEP, and LDTESTIR modes. The later mode latches whatever is presented on the instruction bus into the Instruction Decode latch, allowing the emulator or debugger to "jam" its own instruction stream into the processor to save/restore state and interface with the rest of the system. It is conceivable that this mode could be used as you suggest, but it wouldn't run full speed, since transitions between LDTESTIR and SINGLE-STEP modes would have to be made for each instruction. -- Tim Olson Advanced Micro Devices (tim@amd.com)