Re: MIPS simulator initializes LSI pmon vector table with code

[cgd@broadcom.com]

At 19 Apr 2002 18:06:34 -0300, Alexandre Oliva wrote:
> Ok, so could you please explain to me how these two chunks of code can
> possibly be correct:
> 
> 	if (lsipmon_monitor_base != 0)
> 	  {
> 	    address_word vaddr = (lsipmon_monitor_base + (loop * 4));
> 	    sim_write (sd, vaddr, (char *)&value, sizeof (value));
> 	  }
> 
> (where lsipmon_monitor_base is 0xBFC00200, and loop varies from 0 to
> 23.  I read that as writing pointers into lsipmon_monitor_base)
> 
>       sim_write (sd, 0xBFC00200, (char *) halt, sizeof (halt));
>       sim_write (sd, 0xBFC00380, (char *) halt, sizeof (halt));
>       sim_write (sd, 0xBFC00400, (char *) halt, sizeof (halt));
> 
> (where halt is 64-byte long chunk of code, which means that one of
> these halts overwrites not only its own entry in lsipmon_monitor_base,
> but also the following entry.)

Together, you mean?  And I assume you mean 64-bit rather than
'64-byte'?

(64 bit or 64-byte, I don't see what you mean by 'overwrites its own
entry...')

I think it's clear -- otherwise you wouldn't have had a problem to
begin with -- that the current situation doesn't do what's intended
for lsipmon.  8-)  More towards the bottom...


Well, note that I'm not the author of this code, nor was I a
maintainer when it got into its current state.  I suggest you look at
the diffs between rev 1.1 and 1.2 -- and then consult fche, who made
the change -- to find out why those changes were made.

If you go back to the original code in public rev 1.1, what you'll
find is that the writes of 'halt' to the BFC addrs above was done
_before_ the pmon/lsipmon loop to write the values.


> > I cannot believe that any monitor does what you describe (puts a table
> > of addresses here), as doing so (instead of putting vectors there)
> > would be fundamentally incompatible with the MIPS architecture.
> 
> I stand corrected.  It doesn't write pointers into chose chunks.  I
> misremembered what I had seen.  The values of `value' that are written
> in the first chunk of code as numbers that range from 6 to 28, except
> for the printf service.  However, I don't see how a code sequence that
> halts the machine could possibly fit there as an entry in the vector
> table.

So, you get to these vectors via exceptions (e.g., TLB exceptions,
address errors, etc.)

The action that the 'halt'-writing code accomplishes is that it
arranges to halt the simulator when you get one of these exceptions.
That seems like a reasonable thing to do.


What I believe you want to do here is:

* do the writes to the vector table first, iff you're using any of the
  monitors.

* then do the additional writes as-is if you're using pmon or lsipmon
  as the monitor.

This has the somewhat odd effect that if you're using lsipmon, the BEV
TLB Miss vector doesn't halt the simulator... but for all I know, the
CPUs you're talking about & for which you'd use 'lsipmon' had no TLBs
or something so that point would be moot.  8-)



chris