weiman@jargon.whoi.edu (Bob Weiman) (01/09/91)
If someone is using the new Inmos ANSI C compiler and
toolset perhaps they could anwer a qustion for me. I am
having trouble getting the interactive debugger to run.
I am using a T800 as the debugger TRAM. I have heard
a rumor that you a T801 or T425 for the debugger TRAM
because they have some breakpointing instructions that
th T800 doesn't have. Is this true?
--
Bob Weiman Internet: bweiman@whoi.edu
Woods Hole Oceanographic Institution
Deep Submergence Lab
Woods Hole, MAiann@specialix.co.uk (Ian Nandhra) (01/09/91)
weiman@jargon.whoi.edu (Bob Weiman) writes: >If someone is using the new Inmos ANSI C compiler and >toolset perhaps they could anwer a qustion for me. I am >having trouble getting the interactive debugger to run. >I am using a T800 as the debugger TRAM. I have heard >a rumor that you a T801 or T425 for the debugger TRAM >because they have some breakpointing instructions that >th T800 doesn't have. Is this true? >-- The T800 TRAM and idebug works just fine here. What *exactly* is the problem. -- Ian Nandhra, iann@specialix.co.uk {backbone}!mcsun!ukc!slxsys!iann I am speaking, but | If these are your opinions, then we are in agreement!! not for my employer.| Flames, spelling errors, complaints > /dev/null
nigel@dodo.inmos.co.uk (Nigel Holder) (01/09/91)
In article <1991Jan8.201733.29037@netnews.whoi.edu> weiman@jargon.whoi.edu (Bob Weiman) writes: > >If someone is using the new Inmos ANSI C compiler and >toolset perhaps they could anwer a qustion for me. I am >having trouble getting the interactive debugger to run. >I am using a T800 as the debugger TRAM. I have heard >a rumor that you a T801 or T425 for the debugger TRAM >because they have some breakpointing instructions that >th T800 doesn't have. Is this true? >-- >Bob Weiman Internet: bweiman@whoi.edu The rumour is true that the T425 and T801 have extra instructions to support breakpointing *but* we do document them so it's not really a rumour. However, as far as using the new breakpoint debugger is concerned, the debugger itself requires *any* 32 bit transputer with at least 1 Mbyte (preferably 2 Mbyte) for itself; the rest of the network can consist of any combination of 16 and 32 bit transputers. Setting breakpoints on transputers without hardware breakpoint support (eg. T800, T222 etc.) is still possible with idebug so long as you only set them in low priority processes. This is of course mentioned in the documentation for idebug - have you read it or is it unclear ? (if so tell me for future incorporation). Have you phoned your local INMOS Business Center for help with using the toolset ? (as listed in the toolset documentation). Nigel Holder, Software Group, INMOS Ltd | Tel +44 454 616616 1000 Aztec West | Almondsbury | UK: nigel@uk.co.inmos Bristol BS12 4SQ, UK | US: nigel@inmos.com
jipping@cs.hope.edu (Mike Jipping) (01/09/91)
weiman@jargon.whoi.edu (Bob Weiman) writes: > If someone is using the new Inmos ANSI C compiler and > toolset perhaps they could anwer a qustion for me. I am > having trouble getting the interactive debugger to run. > I am using a T800 as the debugger TRAM. I have heard > a rumor that you a T801 or T425 for the debugger TRAM > because they have some breakpointing instructions that > th T800 doesn't have. Is this true? According to the tech support guy we correspond with, YES it is true. The INMOS C debugger is NOT capable of interactive debugging with T800s, but post-mortems can still be done. Our support guy daid that he thought TRAMs whose model numbers ended in 1 or 5 were capable of interactive debugging, and the rest were not. Mike Jipping Hope College Department of Computer Science jipping@cs.hope.edu (BITNET: JIPPING@HOPE) "The 70's are over old man. Take your mood ring and go home." -- Dana Gould
llw@corwin.eng.yale.edu (Louis L. Whitcomb) (01/09/91)
In article <1991Jan8.201733.29037@netnews.whoi.edu> weiman@jargon.whoi.edu (Bob Weiman) writes: ...I am having trouble getting the interactive debugger to run. Greetings: We have been using the Inmos ANSI C debugger extensively in both interactive and post mortem modes. It does support both interactive and breakpoint debugging on all t8* processors (contrary to some incorrect statements made in net postings). On the processors without breakpoints, the debugger only supports breakpoints on low priority processes. Note that your processors need a fair amount of memory to run the debugger. Note also that, since the debugger is written to support a multitude of target configurations, you need to correctly involk it with command line switches corresponding to your network. For example, to run the debugger in post mortem mode on a network of B011s from a PC with a B004 development card, we use the command "idebug filename.btl /t 2 /sa /a". Read the Inmos documentation carefully to get the switches right for your configuration. Perhaps you could be more specific about what sor of trouble you are having? It works well. The Best, -Louis. -- Louis L. Whitcomb llw@corwin.eng.yale.edu ph: (203) 432-4237 Yale Robotics Laboratory fx: (203) 432-7481 Department of Electrical Engineering, 1968 Yale Station, New Haven, CT 06520
davidb@brac.inmos.co.uk (David Boreham) (01/10/91)
In article <1991Jan9.141133.26616@cs.hope.edu> jipping@cs.hope.edu writes: >weiman@jargon.whoi.edu (Bob Weiman) writes: > >> If someone is using the new Inmos ANSI C compiler and >According to the tech support guy we correspond with, YES it is true. >The INMOS C debugger is NOT capable of interactive debugging with T800s, >but post-mortems can still be done. Our support guy daid that he thought >TRAMs whose model numbers ended in 1 or 5 were capable of interactive >debugging, and the rest were not. > I don't understand this so I'll detail our numbering scheme for those who remain perplexed: All T-Series TRAMs are numbered IMS B4xx-y . The "xx" part of the number is allocated in chronological order, missing out "13" which is reserved for designs we don't ever want to finish :) Some other numbers were missed in order to aviod confusion with other products. For instance, there is no B425. The "y" part is determined by the transputer for "compute only" TRAMs: -1 IMS T212-20 -2 IMS T414-20 -3 IMS T800-20 -4 IMS T800-17 -5 IMS T800-25 -6 IMS T800-30 - -7 IMS T425-20 -8 IMS T425-25 -9 IMS T425-30 -10 IMS T222-20 -11 IMS T801-20 -12 IMS T801-25 -14 IMS T400-20 For I/O and graphics TRAMs, the "y" part is allocated in chronological order for different variations. There are other numbers marked on the actual TRAMs. These are manufacturing build identifiers, used for traceability and tend to incorporate a letter after the product code (IMS B404-5B). Happy New Year. David. David Boreham, INMOS Limited | mail(uk): davidb@inmos.co.uk or ukc!inmos!davidb Bristol, England | (us): uunet!inmos.com!davidb +44 454 616616 ex 547 | Internet: davidb@inmos.com
jipping@cs.hope.edu (Mike Jipping) (01/10/91)
> weiman@jargon.whoi.edu (Bob Weiman) writes: > ...I am having trouble getting the interactive debugger to run. > > Greetings: > > We have been using the Inmos ANSI C debugger extensively in both > interactive and post mortem modes. It does support both interactive > and breakpoint debugging on all t8* processors (contrary to some > incorrect statements made in net postings). Hey! That was me! I'm sorry for the misinformation. I had the same problem and got the answer I gave from my INMOS support technician. > ... On the processors without > breakpoints, the debugger only supports breakpoints on low priority > processes. Then allow me to be real naive. How do I force a process to be a low priority process. I'm aching to do breakpoint debugging... Thanks. Mike Jipping Hope College Department of Computer Science jipping@cs.hope.edu (BITNET: JIPPING@HOPE) "The 70's are over old man. Take your mood ring and go home." -- Dana Gould
llw@corwin.eng.yale.edu (Louis L. Whitcomb) (01/11/91)
In article <1991Jan10.121337.203@cs.hope.edu> jipping@cs.hope.edu (Mike Jipping) writes: ... How do I force a process to be a low priority process. I'm aching to do breakpoint debugging... Greetings: All processes are low priority unless you specify them to be high priority at either the configuration level or when explicitly running a process with the library functions (e.g. ProcRunHigh and ProcRunLow). To interactively debug a program on a network of B011's attached to a B004 in a pc, for example, use the command line "idebug filename.btl /b /2 /sr" to run the network program under the debugger. Then follow the instructions in Section 8.10 of the Inmos C toolset user manual to set inital breakpoints, run the program, resume after breakpointing, etc. It works well. The Best, -Louis. -- Louis L. Whitcomb llw@corwin.eng.yale.edu ph: (203) 432-4237 Yale Robotics Laboratory fx: (203) 432-7481 Department of Electrical Engineering, 1968 Yale Station, New Haven, CT 06520
weiman@jargon.whoi.edu (Bob Weiman) (01/11/91)
I posted the original message concerning hte Inmos
ANSI C interactive debugger. I have switched from
our beta release version to the official release
and it appears to be running OK.
The information that the debugger would only run with
a T801, 805 or T425 is FALSE. I got this wrong information
originally from an Inmos rep who has since called me back
to correct the information. (I believe that you need one
of the above mentioned processors only if you want to be able
to put break points in high priority processes.)
The new manual, as opposed to the beta manual, has a much
better description of running the debugger, including some
good examples.
--
Bob Weiman Internet: bweiman@whoi.edu
Woods Hole Oceanographic Institution
Deep Submergence Lab
Woods Hole, MA