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

[ Thread Index | Date Index | More Archives ]


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 < 
                                curr_cycles = 
(falcon_instr_cycle.cache_cycles - falcon_instr_cycle.head);
                                curr_cycles = 
(falcon_instr_cycle.cache_cycles - CpuInstruction.iSave_instr_tail);

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

                curr_cycles += regs.ce030_instr_addcycles;


"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

> 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

Mail converted by MHonArc 2.6.19+