Re: qcam on NetBSD
> If we must sacrifice readability to the god of speed then please keep
> (and maintain!) the C version of the algorithm alongside the (various)
> assembler versions, presumably protected by C preprocessor directives.
> That way, Joe Sixpack can at least run a slower but functional version
> of the code if for some reason the turbo-charged assembler versions
> don't work.
I agree -- speed is important, but I really don't want to good code
sacrificed to the god of performance.
At this point in time, I don't want to start including assembly
routines in with the code I maintain. I might reconsider if someone
can show a substantial performance difference, *and* we work the
remaining bugs out of the software first. While I'm sure Russell's
right, and the assembly code can be quite a bit faster, there's no
point in outrunning the camera. No matter what happens, the C code
I don't mind splitting the scan code into 4 seperate cases (4/6,
uni-/bi-directional), but I value readibility and maintainibility, and
I'm not in a real hurry to change things.
Scott A. Laird | "But this goes to 18,446,744,073,709,551,615"
email@example.com | - Nigel on his new 64-bit computer