Re: [hatari-devel] Native feature proposal

[tin@xxxxxxxxx]

Note that this could be done with the debugger too, and that way
overhead would be zero cycles for the emulated code.

Had thought about that, but my main caveat was that I didn't see a way of having code output a a warning, if certain timing constraints are not met, compute the average etc.

"Never underestimate the Hatari debugger" as the saying goes - so I wouldn't be surprised at all if even that is possible atm with the current debugger implementation.

So the only thing speaking /for/ a new Natfeat here is the ability to compute sth with and react to the results. The debugger approach clearly beats NatFeats in the timing department.

Did I mention that the debugger is really awesome?

Eero Tamminen

2. Mai 2018 um 23:48

Hi,



I don't think that in itself is a problem, as long as API doesn't
overlap with the other NF APIs, or other ways of doing the same.


Note that this could be done with the debugger too, and that way
overhead would be zero cycles for the emulated code.

One can just add a symbol to a place in the code where one
wants these values to be output, and them add tracing
breakpoint for that symbol in the debugger:
    b pc = show_values :quiet :lock

Breakpoint ":lock" option shows the info (that has been "locked"
to be show on debugger entry), without actually stopping:
CPU=$fc1572, VBL=413, FrameCycles=160334, HBL=0, LineCycles=78, DSP=$0


If that's not enough, one can use this instead:
    b pc = show_values :quiet :trace :file show-values.ini

And do the desired outputs in "show-values.ini" file, e.g:
    e VBL
    e HBL
    e LineCycles
    e FrameCycles
    e CycleCounter

If additional emulation state info variables are needed,
adding those isn't a problem.

Output of above isn't very concise though. If that's a problem,
I accept proposals on what to do to improve that. :-)


    - Eero

Thorsten Otto

2. Mai 2018 um 08:49

On Dienstag, 1. Mai 2018 20:59:34 CEST tin@xxxxxxxxx wrote:

Hi,

here's a proposal for two very handy NF calls I've patched into my
Hatari branch for a while now:

NF_STDERR_NUM: output a number without the need to convert it to a
string on the ST.

There is already a more general version of something like this: DEBUGPRINTF. 
It takes a printf-like string and a variable number of arguments, just like 
printf. Drawback: since the natfeats interface requires all parameters to be 
longs, you have to be careful that all arguments really fulfill that 
requirement. Not a problem when using GCC, but maybe when using compilers like 
Pure-C with 16-bit ints. Also, floating point is not supported by that 
interface. So i normally take a different approach: provide a wrapper function 
nf_debugprintf(), that prints to a static string, then outputs that using 
NF_STDERR.

NF_FRAMEPOSITION: copies frame info (nVBLs, nHBL, nScanlinesPerFrame,
nCyclesPerLine and CyclesPerVBL) into a memory area given by the guest
program. This makes it very easy to time code parts cycle-exact at
runtime and do a quick check on optimizations as well as the average
time a code part takes between frames. Also it's easier to check where
exactly a code runs (relative to the frame start).

That would be very Hatari specific. 

Any objections?

Yes. Please don't  forget that there are other emulators around, and that the 
NatFeats interface is meant to be a general enhancements for those. So please 
don't wildly invent NatFeats that won't be documented, especially when they 
duplicate already existing functionality.

tin@xxxxxxxxx

1. Mai 2018 um 20:59

Hi,

here's a proposal for two very handy NF calls I've patched into my Hatari branch for a while now:

NF_STDERR_NUM: output a number without the need to convert it to a string on the ST. I often output internal state variables of a running programm using NF_STDERR (e.g. taken frames per render, clock-cycles of specific parts, control variables etc.). This way printing these taking almost no cpu time and the developed programs run-time behaviour isn't changed too much.

NF_FRAMEPOSITION: copies frame info (nVBLs, nHBL, nScanlinesPerFrame, nCyclesPerLine and CyclesPerVBL) into a memory area given by the guest program. This makes it very easy to time code parts cycle-exact at runtime and do a quick check on optimizations as well as the average time a code part takes between frames. Also it's easier to check where exactly a code runs (relative to the frame start).

Any objections?