| 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 7:04 PM, Thorsten Otto wrote:
On Mittwoch, 30. September 2020 17:26:14 CEST Eero Tamminen wrote:
You could add an extra parameter to
VDI_Opcode2Name() for the component name (e.g.
"NVDI vX.XX"). By default it would be empty
string.
Theoretically that could be done, but some calls are not only implemented by
NVDI. I took the comments from tos.hyp, but for example fVDI also implements
some of them, and also FSM-GDOS and SpeedoGDOS.
If there are multiple implementations,
component name could be just "GDOS".
I want there to be some distinction to user
about whether plain TOS supports a function
or whether some extra SW is needed for it,
because it can sometimes explain a bug.
Same thing would apply to adding MiNT GEMDOS
call names to GEMDOS tracing.
As those are all for
opcodes >=170, the array should be named like
"names_opcode170".
The intention was to later integrate the opcode5 and opcode11 tables there
too, so they don't have to be treated specially.
>
as now the whole array would
be scanned also for unrecognized opcodes/subcodes
before 170.
Hm, yes theoretically. But the array now contains all known VDI opcodes, so
that would only matter if there actually is an unknown opcode, which is really
unlikely. And in that case, you have to scan the table, anyway.
Ok, sound reasonable.
the final return value for the unknown opcodes
should now be something else than "GDOS?"...
Ok, that should then just be changed to "???", like in other table entries.
Likewise.
But most likely, it will still be some GDOS call which is not yet documented
anywhere.
>
Unconditionally skipping them isn't OK, and that functionality should be
in a separate patch.
Oops. I added that for testing, it was not meant to be part of the patch.
Just drop that part from the patch for now.
Could you provide a new tested patch with the all
the above issues fixed?
However, I'm not yet sure what would be best way
to do that.
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"...
Maybe that could be placed into something like if (callers pc in ROM), but
that may also fail if ROM has for example been copied to TT-RAM, or when using
emutos.prg. The cleanest would maybe to have -trace recognize also the
individual function names, so you can disable it with -trace -vq_key_s etc. (i
think none of them conflicts with other trace options)
Then it would need to go through all subsystems
function call names to find correct ones.
At that point I think it would make sense to add
also support for tracing specific opcodes, but one
can already do that (with opcodes) using tracing
breakpoints. Which has the additional benefit of
providing backtraces to those calls too, if
profiling is enabled and program include symbol
information...
Btw. At least that function name -> opcode mapping
code would be localized, unlike rest of this
feature... Each of the nearly thousand TRACE()
macro calls in the code would eventually need to
check whether its on deny/allow opcode list:
$ git grep LOG_TRACE | wc -l
859
BTW, that check for the subcode *cannot* be made for all opcodes.
Yes, I think it should be done only for opcodes
which actually have subcodes.
During tracing i saw lots of output like
VDI call 129/ 1 (vs_clip)
Subcode 1 is not defined for vs_clip(). The reason is IMHO an incorrect
binding in some libraries, which do not always clear the subcode field and use
static arrays (like in PCGEMLIB). In that case, it will just pass the subcode
from some previous call.
So, showing the subcode always is good thing,
as it may might catch some subtle bug in app.
:-)
- Eero