[hatari-devel] DSP debug reworked

npomarede at corp.free.fr npomarede at corp.free.fr
Sun May 30 22:42:18 CEST 2010


On Sun, 16 May 2010, Eero Tamminen wrote:

> The interrupt handling is earlier already about the heaviest thing in Hatari
> for ST emulation on my 32-bit machine (about the same as the m86k emulation
> itself).  Maybe it's because of 64-bit stuff there? :-)

Maybe, but due to the required precision we can't avoid using 64 bits 
there, or MFP and CPU won't be able to get perfectly in sync regarding 
cycle counting.

>> I'm not sure we require such a level of detail to split log macros
>> between video, sound, ...
>>
>> Current code basically does :
>>  	if (LogTraceFlags & level)
>>  		{ print ... }
>>
>> new possible methods :
>>
>>   1) set LogTraceFlags to Uint64 -> nothing else to change, we now have
>> 64 bits to play with and the test remains fast (apart from dealing with
>> 64 bits int)
>>
>>   2) have a global variable LogTraceOn = true or false and some
>> additional Uint32 to store flags (LogTraceFlags1, LogTraceFlags2, ...)
>>
>> with 2), code could become :
>>  	if ( LogTraceOn )
>>  	{
>>  		if ( level matches LogTraceFlags1 level
>>
>>  			|| level matches LogTraceFlags2 )
>>
>>  			{ print ... }
>>  	}
>
> None of above is necessary with what I proposed.
>
>
> If we would e.g. decide that video.c trace would have its own flags
> variable, we would have just:
>
> in log.h additional define:
> #define LOG_VIDEO_TRACE(level, args...) \
>        if (unlikely(LogTraceVideoFlags & level)) fprintf(TraceFile, args)
>
> And in video.c repace LOG_TRACE with LOG_VIDEO_TRACE.
>
> Only complication would be in log.c log options parsing because it would
> need to set bits in different flag variables.
>

But what you propose is just what I would like to avoid : replacing all 
LOG_TRACE everywhere with LOG_XXX_TRACE. I'm not sure we need to have one 
variable per component (cpu, video, blitter, sound, ...)

>
>> problem is : how do we compare *rapidly* the value of level with several
>> LogTraceFlagsX variables ?
>
> Trivially. :-)

Not if you just modify log.c/.h and don't replace LOG_TRACE by 
LOG_VIDEO_TRACE for example (to avoid changing all actual LOG call syntax 
in all source files).

>
>> I would go for 1st solution, as it requires nearly no changes ; or any
>> other solution that doesn't require to modify all the sources files that
>> have LOG_TRACE calls (only modifications should go to log.c / log.h) as
>> this would come to commit nearly the whole source tree, which is quite
>> overkill and not really readable.
>
> I guess the 64-bit thing could be tried first and if it seems to be causing
> performance issue (would be hard to see though because with macros it's not
> centralized to single place), then use separate flag variables.

In case it causes performance issue, the user can still disable logging at 
compile time. But this should be tried first anyway on a real case.

Nicolas




More information about the hatari-devel mailing list