Hi,
Thanks a lot for answering my previous questions.

I have made some small changes in the Execute component w.r.t. handling 
the data.

Normally, (on line 1241 of ExecuteImpl.cpp), a new store MemoryMessage 
'operation' is constructed with the DataWord set to 0.

However, I wanted to pass on the data coming in from the 
ArchitecturalInstruction to the cache modules. So I made the following 
additions just before the above mentioned line:

#########
DoubleWord mon_dw = anInstructionState->instruction().data();
unsigned long long mon_dw_val_to_mem = 0;
unsigned long long mon_dw_val_orig = mon_dw.getDoubleWord(0);

switch (mon_dw.theValidBits)
{
        case 0xFF:
                mon_dw_val_to_mem = mon_dw_val_orig;
                 break;
        case 0xF0:
                mon_dw_val_to_mem = (mon_dw_val_orig>>32) & 0xFFFFFFFF;
                 break;
        case 0x30:
                mon_dw_val_to_mem = (mon_dw_val_orig>>32) & 0x0000FFFF;
                 break;
        case 0x10:
                mon_dw_val_to_mem = (mon_dw_val_orig>>32) & 0x000000FF;
                 break;
        case 0x0F:
                mon_dw_val_to_mem = mon_dw_val_orig & 0xFFFFFFFF;
                 break;
        case 0x03:
                mon_dw_val_to_mem = mon_dw_val_orig & 0x0000FFFF;
                 break;
        case 0x01:
                mon_dw_val_to_mem = mon_dw_val_orig & 0x000000FF;
                 break;
        case 0x00:
                mon_dw_val_to_mem = 0;
                 break;
        default:
                mon_dw_val_to_mem = 0;
                break;
}

operation = MemoryMessage::newStore(                                     
anInstructionState->instruction().physicalMemoryAddress(),
PhysicalMemoryAddress( 
anInstructionState->instruction().virtualInstructionAddress()),
DataWord(mon_dw_val_to_mem)
);

#######

Can you please confirm if I am handling the data from the 
ArchitecturalInstruction correctly?

Another question related to the above:
I wrote additional case statements in the above such as:

case 0xF3:
                mon_dw_val_to_mem = mon_dw_val_orig & 0xFFFFFFFF0000FFFF;
        break;
case 0xF1:
        mon_dw_val_to_mem = mon_dw_val_orig & 0xFFFFFFFF000000FF;
        break;

However the compiler gives an error saying that the constant is too 
large for a unsigned long long. I was under the assumption that long 
longs are 64-bit. Is that incorrect? How does one handle 64-bit data 
words/values in the SPARC v9 simulator?


Now a question related to verifying the above data:
I want to forward the data to the L1 and L2 caches. I think that simply 
inserting the right DataWord in the MemoryMessage should accomplish this.
But how do I verify that the data values are correct in the L2/L1 caches?

For e.g. I have modified the flexus-test-app by inserting a for loop 
which changes elements of an array. This is the "useful work" done by 
the 'do_work' function. But I was not able to trace the data values 
being read from/written to the array by the threads (there are only two 
threads in my simulation). Can you give me some idea how I can see the 
values so that I can be sure that the data is not getting messed up 
somewhere along the path.

Thanks a lot!
- Mrinal
From twenisch at ece.cmu.edu  Wed May 17 14:49:45 2006
From: twenisch at ece.cmu.edu (Thomas Wenisch)
List-Post: [email protected]
Date: Wed May 17 14:50:36 2006
Subject: [Simflex] Questions about Simflex
In-Reply-To: <[email protected]>
References: <[email protected]>
        <[email protected]>
        <[email protected]>
Message-ID: <[email protected]>

Hi Mrinal,

On Mon, 15 May 2006, Mrinal Nath wrote:

> Hi,
> Thanks a lot for answering my previous questions.
>
> I have made some small changes in the Execute component w.r.t. handling the 
> data.
>
> Normally, (on line 1241 of ExecuteImpl.cpp), a new store MemoryMessage 
> 'operation' is constructed with the DataWord set to 0.
>
> However, I wanted to pass on the data coming in from the 
> ArchitecturalInstruction to the cache modules. So I made the following 
> additions just before the above mentioned line:
>
> #########

<snip code>

> #######
>
> Can you please confirm if I am handling the data from the 
> ArchitecturalInstruction correctly?

The code you sent looks reasonable, but I suggest you test it to be sure. 
Single step a 1-CPU simulation in Simics, and have your code print the 
addresses and values it is receiving, and then confirm them against 
Simics.  You can use the SIM_read_phys_memory function from the simics 
prompt to compare the values to your debug output.

>
> Another question related to the above:
> I wrote additional case statements in the above such as:
>

> case 0xF1:
>       mon_dw_val_to_mem = mon_dw_val_orig & 0xFFFFFFFF000000FF;
>       break;
>
> However the compiler gives an error saying that the constant is too large for 
> a unsigned long long. I was under the assumption that long longs are 64-bit. 
> Is that incorrect? How does one handle 64-bit data words/values in the SPARC 
> v9 simulator?

The compiler assumes that literals are integers (32-bit for most GCC 
targets) by default.  To tell the compiler that a literal should be an 
unsigned long long, you have to add the ULL suffix to the end.  Example:

   case 0xF3:
                mon_dw_val_to_mem = mon_dw_val_orig & 0xFFFFFFFF0000FFFFULL ;
         //                                                Here--^^^
        break;

>
> Now a question related to verifying the above data:
> I want to forward the data to the L1 and L2 caches. I think that simply 
> inserting the right DataWord in the MemoryMessage should accomplish this.
> But how do I verify that the data values are correct in the L2/L1 caches?

Inserting the right data word will pass the data into the caches. 
However, the caches do not currently store these values (they data field 
is basically ignored).  The cache code is littered with "TODO" comments 
that should identify all the places where data has to be moved from one 
data structure to another.  All of these must be implemented. (Caveat: 
While we did try to mark all the places where data must be moved, it is 
possible that we missed some).

>
> For e.g. I have modified the flexus-test-app by inserting a for loop which 
> changes elements of an array. This is the "useful work" done by the 'do_work' 
> function. But I was not able to trace the data values being read from/written 
> to the array by the threads (there are only two threads in my simulation). 
> Can you give me some idea how I can see the values so that I can be sure that 
> the data is not getting messed up somewhere along the path.

I suggest you print the values using DBG_ statements.  There are many 
examples throughout the code.  You can enable debug output from the Simics 
prompt.  There is some documentation on the debug system in the 
Flexus tutorial slides, I suggest you start by looking there.

Regards,
-Tom Wenisch
Computer Architecture Lab
Carnegie Mellon University

Reply via email to