| Re: [hatari-devel] [PATCH] Add some NVDI function names |
[ Thread Index |
Date Index
| More lists.tuxfamily.org/hatari-devel Archives
]
Hi,
On 9/30/20 8:37 PM, Thorsten Otto wrote:
On Mittwoch, 30. September 2020 19:13:22 CEST Eero Tamminen wrote:
>> So far I haven't gotten yet any compelling
>> reason why this large feature would be needed,
>> when one can already trivially filter the extra
>> lines out of Hatari trace output with "grep"...
>
> The mentioned functions are called a lot (all 3 > about 20 times a
second) and thus will make the
> trace log rather large, and also slow down
> emulation.
Compared to data from CPU instruction tracing,
that's nothing. Even when compared to just HW
register access tracing, it's pretty small.
If it's a noticeable performance problem for you,
make sure you've built Hatari with optimizations
and aren't saving the log to a floppy. :-)
(Adding in-Hatari OS function call filtering for
all traced function could cancel any performance
improvement you would get from skipping the given
printf. Grep is optimized for matching text,
so using that may be as fast as doing it in Hatari
would, and there are commands you can use in the
pipeline to remove pipeline buffering/latency.)
Hmpf. Ma email client fooled me, my last post wa snot yet finished ;)
but one
can already do that (with opcodes) using tracing
breakpoints.
Unfortunately, for VDI- (and also AES-) calls that does not work very well in
most cases. In most libraries, there are single vdi() and aes() entry points.
Yes, it's more useful for other OS calls, ones
that don't (potentially) require checking
subcodes.
E.g. allocations and file accesses done through
GEMDOS. I used that quite a lot when profiling
Falcon BadMood, to catch extra Doom resources
usage that Douglas would need to fix or cache.
I've mostly used VDI/AES breakpoints just to
limit what parts of GEM benchmarks are executed,
when profiling EmuTOS, though. :-)
Each of the nearly thousand TRACE()
macro calls in the code would eventually need to
check whether its on deny/allow opcode list:
Erm. I don't get that.....
In the VDI & AES case there's a single place where
to check whether given OS function should be shown
in a trace.
However, this is not the case e.g. with most of
the GEMDOS or (X)Bios functions, because their
trace points show also function arguments from
stack and depending on what is being done,
potentially also some other info.
I.e. these trace outputs don't happen in a single
place, but are all over the code.
In total there are hundreds such trace points,
although not all them are about tracing OS function calls.
THAT would make such a generic tracing feature
very annoying & invasive to implement.
it may might catch some subtle bug in app.
Unfortunately that seems be the case for a lot of older applications
(including GEMINI, for example).
- Eero