Re: [hatari-devel] Native feature proposal

[tin@xxxxxxxxx]

Yes, that is true. I just wanted to /not/ have to use a format string (this lends better to an asm-macro with a small footprint).

NF_STDERR_NUM could take an /optional/ format string, though. That way one can use it as small-footprint number printer or as a full fledged printf. %s would need a special handling (enforcing max string/buffer size) to be on the safe side.

And of course we need a new name then. NF_STDERR_PRINTF? 

Vincent Rivière

1. Mai 2018 um 22:58

A full printf-like NatFeat would be more useful.
Of course, API details should be specified, such as int size (16 or 32-bit) used by %d.

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?