Hi Lu, Take a look at the steps that make install carries out - they are in makefile.install and makefile.checksetup. Most of these items are version checks, and they can be turned off by defining an appropriate variable in makefile.defs.
The one you will need to do by hand is the library installation in makefile.install. It copies the gcc libstdc++ and other libraries into the Simics distribution, to force simics to use versions of the libraries that are compatible with flexus. You will need to locate these libraries on your system, perhaps in /lib, /usr/lib, or /usr/local/lib. Try running ldd on a C++ program that you compiled with g++. It should give you the location. Once you find the files, manually copy them to the correct locations in the simics tree, as done in makefile.install. Regards, -Tom Wenisch On Tue, 25 Oct 2005, lu peng wrote: > > Hi Tom, > > Thanks for your previous reply. I have handled that filename problem. Now I > am trying to install simflex on another machine with Redhat linux Enterprise > version > kernal 2.6.9-22.ELsmp. It was equipped with gcc version 3.4.4 20050721 (Red > Hat 3.4.4-2) and gmake 3.80. My problem is that path setting. Seems the gcc > doesn't > have one separate directory. It can be find at /usr/bin/gcc. I don't know how > to set GCC_PATH. I tried to set it to /usr. However, there was an error > message when > I tried 'make install': > > cp: cannot stat `/usr/lib/libgcc_s.so.1': No such file or directory > ln: `/pengdata/simflex/simics-2.0.28/x86-linux/sys/lib/libstdc++.so.5': File > exists > Installed GLIBC libraries from (GCC_LIB_PATH) in > /pengdata/simflex/simics-2.0.28/x86-linux/sys/lib > > How do I hand this problem? > > Thanks, > > Lu > > > > > > From shanlu at cs.uiuc.edu Tue Oct 25 16:19:08 2005 From: shanlu at cs.uiuc.edu (shan) List-Post: [email protected] Date: Tue Oct 25 16:19:38 2005 Subject: [Simflex] CMP cache coherence protocol question (fwd) In-Reply-To: <pine.lnx.4.53l-ece.cmu.edu.0510251548580.10...@dalmore.ece.cmu.edu> Message-ID: <[email protected]> I see. Emm, I am not sure if I catch the idea. My current understanding is, for example, the 'owner' means which L1 or L2 caches own the writable version of the block. If the current MESI state is 'S', then the owner is the L2 cache and the copies of this cache line in all sharer do not have 'modifiable' privilege. Is my understanding correct? B.T.W., usually how can I tell what's the receiver of a message from the code? In the cache PiranhaCacheXXX files, there are a lot of SendRequest, are those messages send to L2 cache itself, if the request's coreIndx is not specially set? Thanks very much shan -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Thomas Wenisch Sent: Tuesday, October 25, 2005 1:50 PM To: [email protected] Subject: Re: [Simflex] CMP cache coherence protocol question (fwd) Hi Shan, See below. We will try to get the state diagram out soon. Regards, -Tom Wenisch ---------- Forwarded message ---------- List-Post: [email protected] Date: Tue, 25 Oct 2005 13:53:49 -0400 (EDT) From: Jared C. Smolens To: [email protected] Subject: Re: [Simflex] CMP cache coherence protocol question Excerpts From "shan" <[email protected]>: [Simflex] CMP cache coherence proto: "shan" <[email protected]> >Hi Tom, > Is there some document or something explaining the cache coherence for > CMP in the SimFlex? I know the general MOSI protocol and I read the >PiranhaCache-Controller files, but maybe because I am not very familiar >with the CMP and cache coherence, I still do not understand this module >very well. I am preparing the state diagram for distribution. Stay tuned. > The document said the SimFlex CMP has private L1 and shared L2. Does >that mean there are only one L2 and only one directory shared by all >cores? Yes. We maintain a logical directory at a single, shared L2 in CMPFlex. The directory covers all lines in the CMP core. >Is the M-E-S-I states shared by all cores? The coherence states (including transient states) are maintained in a directory structure at the shared L2. The L1 caches have the same states as in DSMFlex (permutations of Valid, Modifiable, and Dirty bits). > Does the L1 cache in CMP need to be configured somehow different from > that in the Uni-processor scenario? Yes, there is one difference from the Uhiprocessor/DSMFlex configurations: the EvictClean option is set to true in CMPFlex. This option causes clean lines to be sent to the L2, instead of being silently dropped on replacement. This models Piranha's use of the shared cache as a large "victim cache" for L1 replacements. >I didn't find the difference in the >wiring.cpp. However, shouldn't the L1 cache at least be write-through >instead of write-back? The private caches are still write-back, but both clean and dirty lines are written back to the shared cache on replacement. > Sorry to take your time with so many questions. > >Thanks >Shan Jared Smolens ----------- Electrical and Computer Engineering www.rabidpenguin.org ------------- Carnegie Mellon University _______________________________________________ SimFlex mailing list [email protected] https://sos.ece.cmu.edu/mailman/listinfo/simflex SimFlex web page: http://www.ece.cmu.edu/~simflex
