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"
scott@laird.com  |                - Nigel on his new 64-bit computer