Hi all,
I am using the FC4 kernel 2.6.15-1. I am not able to get any simulators 
under Flexus (UniFlex or CMPFlex or UniFlex-x86) to compile on this 
kernel. I get an error saying

"/usr/include/pthread.h:455: error: '__jmp_buf' does not name a type"

Are there any known issues with FC4 and Flexus? I know of a couple of 
other ppl who got it to compile on 2.6.7. Is there any problem with this 
kernel, or with FC4 and flexus?

Thanks for the help.
Pradeep.

PS: I am able to get it to compile on 2.4.21, and am a little skeptical 
about downgrading my kernel. Want to keep this as last resort :).
From etlandfill at gmail.com  Tue May 23 21:08:43 2006
From: etlandfill at gmail.com (James Larson)
List-Post: [email protected]
Date: Tue May 23 21:08:49 2006
Subject: [Simflex] General design questions
Message-ID: <[email protected]>

Hi, my name is James Larson and I've been using SimFlex to do research on
CMP cache structures.  I have some design questions for the makers of
SimFlex.

First, what made you choose the Piranha architecture?   I'm sure it makes
things easier since it's based on Alpha so Simics support would be easier,
but there must be more to it than that.  Piranha uses an exclusive L2 cache,
but inclusive caches seem to be a little more standard (from what I've
read).

The research I'm doing would involve a fairly major overhaul of some of the
SimFlex structure (I'd rather not go into the specifics over the mailing
list) and I'm trying to decide which direction to go - directory-based or
non-scalable, exclusive or inclusive, etc.  Our research would likely only
involve L2 on one chip, so the L1-L2 protocol doesn't necessarily need to be
scalable, but if the number of cores per chip keeps expanding,
directory-based still may be the way to go.  Any insight as to what went
into the SimFlex design or suggestions of paths to avoid would be
appreciated.

Thanks in advance for the help and for the previous help with my
installation problems

~James
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
http://sos.ece.cmu.edu/pipermail/simflex/attachments/20060523/53250442/attachment.html
From twenisch at ece.cmu.edu  Wed May 24 01:33:07 2006
From: twenisch at ece.cmu.edu (Thomas Wenisch)
List-Post: [email protected]
Date: Wed May 24 01:33:26 2006
Subject: [Simflex] Compiling flexus on FC4
In-Reply-To: <[email protected]>
References: <[email protected]>
Message-ID: <[email protected]>

Hi Pradeep,

On Tue, 23 May 2006, Pradeep Ramachandran wrote:

> Hi all,
>
> "/usr/include/pthread.h:455: error: '__jmp_buf' does not name a type"

We have seen this error when compiling 
components/TraceTracker/TraceTracker.cpp on Fedora Core systems.

It can be fixed in
   components/TraceTracker/SharingTracker.hpp
by moving the 6th line:
    #include <boost/pool/pool.hpp>
to be included first (i.e., to the 3rd line).

However, you will still have further problems with GLIBC compatability 
issues on Fedora Core 4 and 5.  See this post in the mailing list 
archives:

https://sos.ece.cmu.edu/pipermail/simflex/2006-April/000195.html

Fixing the Simics/Flexus/Fedora Core library incompatibility is on my todo 
list, and will happen soon.  However, if you don't want to wait, you will 
have to use another Linux distribution in the mean time.

Regards,
-Tom Wenisch

>
> Are there any known issues with FC4 and Flexus? I know of a couple of other 
> ppl who got it to compile on 2.6.7. Is there any problem with this kernel, or 
> with FC4 and flexus?
>
> Thanks for the help.
> Pradeep.
>
> PS: I am able to get it to compile on 2.4.21, and am a little skeptical about 
> downgrading my kernel. Want to keep this as last resort :).
> _______________________________________________
> SimFlex mailing list
> [email protected]
> https://sos.ece.cmu.edu/mailman/listinfo/simflex
> SimFlex web page: http://www.ece.cmu.edu/~simflex
>
From jsmolens+ at ece.cmu.edu  Wed May 24 01:38:09 2006
From: jsmolens+ at ece.cmu.edu (Jared C. Smolens)
List-Post: [email protected]
Date: Wed May 24 01:38:15 2006
Subject: [Simflex] General design questions
Message-ID: <[email protected]>

Hi James, 

See inline....

Excerpts From "James Larson" <[email protected]>:
 [Simflex] General design questions: "James Larson" <[email protected]
>Hi, my name is James Larson and I've been using SimFlex to do research 
on
>CMP cache structures.  I have some design questions for the makers of
>SimFlex.
>First, what made you choose the Piranha architecture?   I'm sure it 
makes
>things easier since it's based on Alpha so Simics support would be 
easier,

We implemented a Piranha-like protocol because there is very good 
published work on both the DSM and CMP designs (specifically Barroso et 
al., ISCA'00).  We also had in-house expertise.

>but there must be more to it than that.  Piranha uses an exclusive L2 
cache,
>but inclusive caches seem to be a little more standard (from what I've
>read).

Piranha uses a "non-inclusive" L2.  It's neither inclusive nor exclusive. 
 See the reference above for details. 

>The research I'm doing would involve a fairly major overhaul of some of 
the
>SimFlex structure (I'd rather not go into the specifics over the mailing
>list) and I'm trying to decide which direction to go - directory-based 
or
>non-scalable, exclusive or inclusive, etc.  Our research would likely 
only
>involve L2 on one chip, so the L1-L2 protocol doesn't necessarily need 
to be
>scalable, but if the number of cores per chip keeps expanding,
>directory-based still may be the way to go.  Any insight as to what went
>into the SimFlex design or suggestions of paths to avoid would be
>appreciated.
>Thanks in advance for the help and for the previous help with my
>installation problems

I'm not sure exactly what you're asking here.  You're probably best off 
working out a way to keep the existing coherence protocol functionality 
intact, but changing the timing and datapaths/queues properly for 
whatever you wish to model.  

For example, the PiranhaDirectory functionally provides coherence as one 
big, flat, idealized directory, although it actually models a CMP similar 
to Piranha, with duplicate L1 tags at the L2.

Cheers,

Jared


Jared Smolens ----------- Electrical and Computer Engineering
www.rabidpenguin.org ------------- Carnegie Mellon University
jsmolens AT ece.cmu.edu ------ HH A-313 ------ Pittsburgh, PA

Reply via email to