* build/ALPHA_SE/tests/fast/quick/00.hello/alpha/linux/inorder-timing
passed.
* build/ALPHA_SE/tests/fast/quick/00.hello/alpha/linux/simple-atomic passed.
* build/ALPHA_SE/tests/fast/quick/00.hello/alpha/linux/o3-timing passed.
*
I just did. Surprisingly when I upgraded gcc to 4.3.something I forgot
to source /env/profile so I was still using 4.1. When I really upgraded
to 4.3, it still tries to execute the vtable, but since there's a
different address it gets an undefined opcode exception instead what I'm
assuming is a
(Is there a reason we're not having this conversation on m5-dev? I
moved it back there for posterity, and in case anyone else wants to
chime in. Note that we're discussing better processing of the C++
code snippets in the ISA description language.)
On Tue, Aug 25, 2009 at 1:08 AM, Gabe
(Redirecting this one to m5-dev too. To keep these threads more
manageable I'm just responding to the parts related to the original
topic of splitting up decoder.cc.)
On Mon, Aug 24, 2009 at 12:39 AM, Gabe Blackgbl...@eecs.umich.edu wrote:
Steve Reinhardt wrote:
My thought was
that a key
I would like to follow this thread at least lightly as I often have to
dibble and dabble into ISA descriptions...
I believe the end-goal is : better processing of the C++ code snippets in
the ISA description language.
and the motivation for it is (please correct or add on here):
- integration of
(Splitting this off-list thread into a third part.)
On Mon, Aug 24, 2009 at 12:39 AM, Gabe Blackgbl...@eecs.umich.edu wrote:
Steve Reinhardt wrote:
On Sun, Aug 23, 2009 at 11:21 PM, Gabe Blackgbl...@eecs.umich.edu wrote:
Along those lines, something I've considered for quite a while, tried
On Tue, Aug 25, 2009 at 1:59 PM, Gabriel Michael
Blackgbl...@eecs.umich.edu wrote:
Quoting Steve Reinhardt ste...@gmail.com:
- Pass by reference operands should also just be flagged as errors,
since there's no way to know if the operand is read, written, or both.
It's more difficult than
On Tue, Aug 25, 2009 at 6:30 PM, Gabriel Michael
Blackgbl...@eecs.umich.edu wrote:
Actually I was hoping that you wouldn't have to include all the .hh
files. If the main decoder in main_decoder.cc calls out to a
subdecoder for x87 ops in x87_decoder.cc, then a header that declares
the
Quoting Steve Reinhardt ste...@gmail.com:
On Tue, Aug 25, 2009 at 6:30 PM, Gabriel Michael
Blackgbl...@eecs.umich.edu wrote:
Actually I was hoping that you wouldn't have to include all the .hh
files. If the main decoder in main_decoder.cc calls out to a
subdecoder for x87 ops in
Probably the easiest way would just be to take a current decoder.cc,
hack it up manually to match one of the thigns we're proposing, then
invoke gcc manually on the result and time it. (Not necessarily easy
in an absolute sense, but it's just a one-off try so there's no point
in doing
On Tue, Aug 25, 2009 at 6:56 PM, Gabriel Michael
Blackgbl...@eecs.umich.edu wrote:
The decode cache is being used. The cache is keyed on ExtMachInsts, and x86
translates the stream of instruction bytes into those before they hit the
decoder. X86 defines those as a structure that holds all the
Good point... if we wanted to be completely safe we'd either have to
require a prototype to be in scope or forbid using instruction
operands directly as function call operands altogether.
I feel like I can probably help with some useful ideas, but I don't
have a good enough picture of what's
I see no mention of specific individuals in my comment! A lot depends
on whether you can hack out a few contiguous 30,000-line chunks or if
you'd have to do a lot of interleaving a few lines at a time to get it
to work. Even in the latter case, some emacs macro creativity could
possibly go
nathan binkert wrote:
I see no mention of specific individuals in my comment! A lot depends
on whether you can hack out a few contiguous 30,000-line chunks or if
you'd have to do a lot of interleaving a few lines at a time to get it
to work. Even in the latter case, some emacs macro
I am out of the office until 1 October 2009.
Your mail regarding will be read when I return.
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
nathan binkert wrote:
Good point... if we wanted to be completely safe we'd either have to
require a prototype to be in scope or forbid using instruction
operands directly as function call operands altogether.
I feel like I can probably help with some useful ideas, but I don't
have a
(Getting this back on the list again...)
On Tue, Aug 25, 2009 at 10:32 PM, Gabe Blackgbl...@eecs.umich.edu wrote:
Steve Reinhardt wrote:
On Tue, Aug 25, 2009 at 9:46 PM, Gabe Blackgbl...@eecs.umich.edu wrote:
Steve Reinhardt wrote:
On Tue, Aug 25, 2009 at 6:56 PM, Gabriel Michael
Steve Reinhardt wrote:
(Getting this back on the list again...)
On Tue, Aug 25, 2009 at 10:32 PM, Gabe Blackgbl...@eecs.umich.edu wrote:
Steve Reinhardt wrote:
On Tue, Aug 25, 2009 at 9:46 PM, Gabe Blackgbl...@eecs.umich.edu wrote:
Steve Reinhardt wrote:
On
18 matches
Mail list logo
