Path: utzoo!mnetor!uunet!lll-winken!lll-tis!ames!mailrus!tut.cis.ohio-state.edu!bloom-beacon!athena.mit.edu!peter
From: peter@athena.mit.edu (Peter J Desnoyers)
Newsgroups: comp.arch
Subject: Re: debugging on a VLIW machine
Message-ID: <4889@bloom-beacon.MIT.EDU>
Date: 26 Apr 88 14:09:26 GMT
References: <8860@sol.ARPA> <365@m3.mfci.UUCP>
Sender: daemon@bloom-beacon.MIT.EDU
Reply-To: peter@athena.mit.edu (Peter J Desnoyers)
Organization: Massachusetts Institute of Technology
Lines: 19
Keywords: vliw, debugger

In article <365@m3.mfci.UUCP> genly@multiflow.com (Chris Hind Genly) writes:
>In article <8860@sol.ARPA> bukys@cs.rochester.edu (Liudvikas Bukys) writes:
>>I'm curious... to run a debugger on a Multiflow Trace, and make any sense
>>out of what you see, I suppose that you have to compile it with trace
>>scheduling and other hairy optimizations off?  Is this true?
>
>Short answer: Trace scheduling doesn't make the problem any worse.
>
I've gotten confused enough by debugging 68000 code at the source
level. Under some conditions, the Apollo C compiler will merge code
for parts of separate cases of a switch statement. Thus the debugger
thinks that you jumped by some magic from the middle of case 10 to
case 1. Debugging Multiflow code can't be much worse, as long as it
doesn't inline user subroutines. The only problem I can see is that
the current line might be off by one or two (although it should always
be able to tell whether the next instruction should call a subroutine)
and that steps might cover quite a few lines of code.

				Peter Desnoyers
				peter@athena.mit.edu