[B2-devel] Reason for Git commit ceed8dca on github.com/tycho/sheepshaver

[Robert M. <mr...@gm...>]

Oh, yes, I see now!

Yes, it looks like an optimization, aimed at a case where a block of
code is pre-decoded and then the PC jumps to a slightly earlier
address (and then, I'd assume, the whole thing gets purged, then later
the same thing happens again).

Perhaps "tycho" (Steven Noonan) has a program that is made faster by
this commit. It's been 2.5 years (2010 Dec 5) but maybe he remembers,
so I'm CC'ing him here.

On 6/16/12, Alexei Svitkine <ale...@gm...> wrote:
> PPC_DECODE_CACHE is enabled by default in the current CVS TOT.
>
> (The commit I linked too re-enabled it because that fork had disabled it at
> some point. My comments were about the other change that moved a few lines
> of code into a for loop.)
>
> On Sat, Jun 16, 2012 at 3:54 PM, Robert Munafo <mr...@gm...> wrote:
>
>> PPC_DECODE_CACHE enables a memory block decode_cache_p which holds up
>> to 32768 consecutive results of decode(opcode) for a block of
>> consecutive PPC instructions (32-bit words).
>>
>> There is a profiling function enabled by PPC_PROFILE_COMPILE_TIME
>> which will record the amount of CPU time used by the decode cache
>> function, printing "compile" vs "predecode" time vs total emulation
>> time.
>>
>> I'm also prone to wonder why PPC_DECODE_CACHE was disabled by default
>> -- it seems that if Gwenole went to all that effort implementing a
>> decode cache (it's about 150 lines of code), why would it be disabled
>> by default?
>>
>> On 6/16/12, Alexei Svitkine <ale...@gm...> wrote:
>> > For example, let's take this commit by Tycho which kallisti5 pulled:
>> >
>>
>> https://github.com/tycho/sheepshaver/commit/ceed8dca09fd5e5fe4e1bf9127d628382cb0f350
>> >
>> > Presumably this makes something faster. Maybe it does, it looks
>> plausible -
>> > [...]
>>

-- 
  Robert Munafo  --  mrob.com
  Follow me at: gplus.to/mrob - fb.com/mrob27 - twitter.com/mrob_27 -
mrob27.wordpress.com - youtube.com/user/mrob143 - rilybot.blogspot.com