Re: [hatari-devel] Most wanted debugger/profiler feature or convenience?

[Eero Tamminen <oak@xxxxxxxxxxxxxx>]

Hi,

On perjantai 12 huhtikuu 2013, Douglas Little wrote:
> > What's your most wanted debugger/profiler feature or convenience?
>
> I thought of one more thing that would interest me - being able to see
> the instruction head/tail cycle information either in the debugger or as
> part of the profile export (for 68020+).

Currently this is only related code in (WinUAE cycle exact) CPU core:
---------------
                /* Laurent : if 68030 instr cache is on, not frozen and 
nohitcache miss, cycles are computed with head / tail / and cache_cycles
                 *           else, cycles are equal to non cache cycles.
                 */
                falcon_instr_cycle = regs.ce030_instr_cycles;

                if ((currprefs.cpu_model == 68030) && ((r->cacr & 3) == 1) 
&& (CpuInstruction.iCacheMisses == 0)) { // not frozen and enabled
                        if (falcon_instr_cycle.head < 
CpuInstruction.iSave_instr_tail)
                                curr_cycles = 
(falcon_instr_cycle.cache_cycles - falcon_instr_cycle.head);
                        else
                                curr_cycles = 
(falcon_instr_cycle.cache_cycles - CpuInstruction.iSave_instr_tail);

                        CpuInstruction.iSave_instr_tail = 
falcon_instr_cycle.tail;
                }
                else {
                        curr_cycles = falcon_instr_cycle.noncache_cycles;
                }

                curr_cycles += regs.ce030_instr_addcycles;

                M68000_AddCycles(curr_cycles);
---------------

"curr_cycles" & "falcon_instr_cycle" are variables local to that function,
CpuInstruction is global.

I.e. "iSave_instr_tail" is the only thing that is currently available
to profiler.


> This information can only be found in timing data sheets and is
> practically impossible to use because the information is never seen in
> context. Nobody can remember so many values. If they are shown next to
> the instructions in real code, there is suddenly a hope of re-scheduling
> for them. There might even be an easy way to indicate effective
> instruction 'overlaps' in the profiler (although 'by eye' would be a
> good start).

How do you think this information should be visible in the profile data?

Note that adding more information to profile can bloat the memory usage
a lot.  For CPU side I'm already using 32-bit counters for this reason,
but maybe this information could be something one can enable with some
build time define (it should be pretty small amount of code in profiler
side).


> I did some experiments years ago with this and found some timing effects
> on 68030 from simply reordering instructions. The effects were mainly
> around memory read/write operations but they probably extend to normal
> instructions too and may have involved head/tail timings.
> 
> This sort of thing doesn't require perfect emulation to be useful - it's
> more of an auto-documentation thing affecting disassembly and probably of
> interest only when hand-optimizing small areas of code. It does depend on
> accurate cycle information entered from the datasheets but I expect it's
> already in there?

Data is in src/cpu/falcon_cycle030.h (WinUAE specific).


> It's hardly an important feature, and the effects/opportunities may be
> small - but it would allow some experiments to be done which are not
> tempting otherwise.

Such information & experiments would also allow verifying the data
on real devices and correcting found emulation issues...


	- Eero