On Tue, Sep 15, 2009 at 5:14 AM, Gabe Black wrote:
>>
>> I'll take a look at trying to do something semi-automatic to split
>> things up. In addition to putting the decide function in a separate
>> file, maybe we could add a directive like
>>
>> set decoder_output "";
>>
>> that would cause all
Steve Reinhardt wrote:
> On Tue, Aug 25, 2009 at 7:07 PM, Steve Reinhardt wrote:
>
>> On Tue, Aug 25, 2009 at 6:56 PM, Gabriel Michael
>> Black wrote:
>>
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 prop
On Tue, Aug 25, 2009 at 7:07 PM, Steve Reinhardt wrote:
> On Tue, Aug 25, 2009 at 6:56 PM, Gabriel Michael
> Black wrote:
>>
>>> 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
On Wed, Aug 26, 2009 at 12:57 PM, Gabe Black wrote:
>> 1. Get StaticInst for PC X (if any).
>> 2. Read the StaticInst's ExtMachInst to learn that the original
>> instruction it represents occupied N bytes, and what those bytes were.
>> 3. Compare the N bytes in memory at PC X with the N bytes store
Steve Reinhardt wrote:
> On Tue, Aug 25, 2009 at 11:03 PM, Gabe Black wrote:
>
>> The problem is that you need the displacement/immediate to actually do
>> the cache look up since those are part of the ExtMachInst and are
>> factored into a match. Those could be ignored for a preliminary lookup,
On Tue, Aug 25, 2009 at 11:03 PM, Gabe Black wrote:
>
> The problem is that you need the displacement/immediate to actually do
> the cache look up since those are part of the ExtMachInst and are
> factored into a match. Those could be ignored for a preliminary lookup,
> read in if there's a match,
Steve Reinhardt wrote:
> (Getting this back on the list again...)
>
> On Tue, Aug 25, 2009 at 10:32 PM, Gabe Black wrote:
>
>> Steve Reinhardt wrote:
>>
>>> On Tue, Aug 25, 2009 at 9:46 PM, Gabe Black wrote:
>>>
>>>
Steve Reinhardt wrote:
> On Tue, Aug 25,
(Getting this back on the list again...)
On Tue, Aug 25, 2009 at 10:32 PM, Gabe Black wrote:
> Steve Reinhardt wrote:
>> On Tue, Aug 25, 2009 at 9:46 PM, Gabe Black wrote:
>>
>>> Steve Reinhardt wrote:
>>>
On Tue, Aug 25, 2009 at 6:56 PM, Gabriel Michael
Black wrote:
> That
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 c
Steve Reinhardt wrote:
> On Tue, Aug 25, 2009 at 6:56 PM, Gabriel Michael
> Black 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
> 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
On Tue, Aug 25, 2009 at 6:56 PM, Gabriel Michael
Black 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 relevant
> informa
> > 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
> > i
Quoting Steve Reinhardt :
> On Tue, Aug 25, 2009 at 6:30 PM, Gabriel Michael
> Black 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
On Tue, Aug 25, 2009 at 6:30 PM, Gabriel Michael
Black 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 instruction object
Quoting Steve Reinhardt :
> (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 Black wrote:
>> Steve Reinhardt wrote:
>>>
>>> My thoug
The original issue is that the x86 decoder.cc is getting huge and
takes several minutes to compile, so we'd like to split it up into
independent .cc files that can be compiled separately just to speed up
compilation.
Since this involves changing the ISA parser, this discussion has
evolved into mul
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 o
(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 Black wrote:
> Steve Reinhardt wrote:
>>
>> My thought was
>> that a key problem is that, b
19 matches
Mail list logo
