On Tue, Jul 21, 2009 at 4:38 PM, nathan binkertn...@binkert.org wrote:
I've noticed that scons creates and runs the SLICC parser every time
you build. Is this absolutely necessary? It seems to slow down the
build quite a bit, especially when recompiling a minor change.
This shouldn't be
Here is an output from a build after nothing changes, where I have the
parser print when it runs.
Which parser? The lex/yacc one or the python one? If it's the
former, I'll try to fix it. If it's the latter, that parser has to be
run, otherwise SCons won't know what files are being
On Tue, Aug 4, 2009 at 2:10 AM, nathan binkertn...@binkert.org wrote:
Here is an output from a build after nothing changes, where I have the
parser print when it runs.
Which parser? The lex/yacc one or the python one?
The Python one.
If it's the
former, I'll try to fix it. If it's the
Which parser? The lex/yacc one or the python one?
The Python one.
If it's the
former, I'll try to fix it. If it's the latter, that parser has to be
run, otherwise SCons won't know what files are being generated. I can
check to see if there is any real performance impact from doing that,
Great. Being able to diff the two sets a files will certainly ease debug.
I hope you don't mind me asking, but why does the fragility of generated code
matter? One should never modify generated code and only rarely look at it.
I'm interested to hear your ideas about how moving SLICC to python
Just an FYI, I'm currently making changes to both the parser and code
generator. I should be able to push those today if you want to hold
off on the conversion.
-Derek
On Tue, Aug 4, 2009 at 9:58 AM, Beckmann, Bradbrad.beckm...@amd.com wrote:
Great. Being able to diff the two sets a files
Yes, especially with the limited error messages SLICC spits out at the
moment. When they aren't deleted it's difficult to even narrow down
how far SLICC makes it before it fails; If they are deleted you can at
least get an idea of which file SLICC gets stuck on.
-Derek
On Mon, Aug 3, 2009 at
I was able to get better messages out of the parser by changing the
exception handler. It seems that the version of python (2.4.6)
installed at Wisconsin doesn't like the way it's currently handled.
If you change the yacc.parse call to:
try:
results = yacc.parse(file(filename, 'r').read()
I hope you don't mind me asking, but why does the fragility of generated code
matter? One should never modify generated code and only rarely look at it.
I'm referring to the generator itself. It's pretty hard to follow
what's going on, so if you want to modify the generator itself, you
need
On Tue, Aug 4, 2009 at 10:46 AM, nathan binkertn...@binkert.org wrote:
I hope you don't mind me asking, but why does the fragility of generated
code matter? One should never modify generated code and only rarely look at
it.
I'm referring to the generator itself. It's pretty hard to follow
Just an FYI, I'm currently making changes to both the parser and code
generator. I should be able to push those today if you want to hold
off on the conversion.
Ok, no problem. Let me know if you need any help updating parser.py.
Also, for those of you SLICC experts out there, I'm curious
changeset 0e78ffeebffd in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=0e78ffeebffd
description:
slicc: better error messages when the python parser fails
diffstat:
1 file changed, 11 insertions(+), 4 deletions(-)
src/mem/slicc/parser/parser.py | 15 +++
Yes, especially with the limited error messages SLICC spits out at the
moment. When they aren't deleted it's difficult to even narrow down
how far SLICC makes it before it fails; If they are deleted you can at
least get an idea of which file SLICC gets stuck on.
Ok. I spent some time trying
I think the folks at Wisconsin can best speak about the MIF code generator. It
was used to formally verify the correctness of protocols. I'm not sure if any
current projects plan to use that support.
The CHECK_INVALID_RESOURCE_STALLS was something I created many years ago to
ensure that all
The parsing errors are much better. Thanks!
Brad
-Original Message-
From: m5-dev-boun...@m5sim.org [mailto:m5-dev-boun...@m5sim.org] On Behalf Of
nathan binkert
Sent: Tuesday, August 04, 2009 9:38 AM
To: M5 Developer List
Subject: Re: [m5-dev] Scons cleaning
Yes, especially with the
Now that the other GEM5 issues are mostly resolved (thanks everyone!), I wanted
to discuss the protocol directory issue in more detail. I'm completely fine
with recompiling all files when changing protocols. I would just like the
ability to have two different M5 binaries, using different
Now that the other GEM5 issues are mostly resolved (thanks everyone!), I
wanted to discuss the protocol directory issue in more detail. I'm
completely fine with recompiling all files when changing protocols. I would
just like the ability to have two different M5 binaries, using different
On Tue, Aug 4, 2009 at 1:33 PM, nathan binkertn...@binkert.org wrote:
Now that the other GEM5 issues are mostly resolved (thanks everyone!), I
wanted to discuss the protocol directory issue in more detail. I'm
completely fine with recompiling all files when changing protocols. I would
Hi,
There is a small bug in the initialization of DATA_MESSAGE_SIZE (which is used
by the Network).
In src/mem/ruby/network/Network.hh
there is this line:
const int DATA_MESSAGE_SIZE = (RubySystem::getBlockSizeBytes()+8);
The problem is that RubySystem's init function (which sets the block
On Tue, Aug 4, 2009 at 9:18 PM, Krishna, Tushartushar.kris...@amd.com wrote:
Hi,
There is a small bug in the initialization of DATA_MESSAGE_SIZE (which is
used by the Network).
In src/mem/ruby/network/Network.hh
there is this line:
const int DATA_MESSAGE_SIZE =
20 matches
Mail list logo
