At Wed, 9 Sep 2020 10:53:09 -0400 (EDT), Mouse wrote: > >>> audioamd(4) has many assembly code (though they look very old stuff). > >> [...] I see no assembly code in arch/sparc/dev/audioamd* on 5.2 [...] > > It's in sparc/sparc/amd7930intr.s. : > Personally, I would be inclined to preserve that. It handles the > interrupt entirely in the trap window, which, for something that > interrupts frequently, can significantly lessen the impact of the > interrupts on performance. Isaki-san did not give any indication what > motivated the removal of that assembly (and presumably its replacement > with C), but I would hesitate to do it without, at the very least, > measuring the performance impact of such a change.
Thank you for comment. As you said, there were too little description about this... am7930intr.s seems have been ported from C as a fast interrupt path. But it already has been disabled 11 years ago due to adapt to MI softint(9) [*]. Therefore, "asm vs C" was not a main topic here. Sorry for confusing. *: http://mail-index.netbsd.org/source-changes/2009/12/19/msg004585.html In addition, I changed the buffer structure used in interrupt handler for sharing. For these two reasons (or even if I have not changed the structure, for one reason above), to enable fast path again would require manpower. For such substitutable assembly code, unless someone continues to maintain them well, it should be removed, I personally think. > Yes, code sharing > is good - other things being equal. I suspect, though I haven't > measured it either, that "other things" are *not* equal here, that > replacing that assembly code with C (or, more precisely, the associated > potential window spilling) would have a significant impact on > performance at higher sample rates. I think that am7930 works only at 8000Hz. Does sparc's one support sample rate other than 8000Hz? Thanks, --- Tetsuya Isaki <[email protected] / [email protected]>
