rainwarrior wrote:
tepples wrote:
Is it possible to compute each sample of "Crowd" in exactly 224 cycles on the MOS 6502?
What's your estimate for a "naive" implementation? (Why does it have to be exactly 224? I'd imagine it would still be musically recognizable at a range of speeds.)
I was mostly trying to rule out jitter-fests due to implementations that aren't constant time, such as an
inc/bne implementation of
t++ or a looping implementation of the term with the variable shift amount. A constant time implementation of
t++ alone would take 34 cycles:
Code:
clc
lda #1
adc t_0
sta t_0
lda #0
adc t_8
sta t_8
lda #0
adc t_16
sta t_16
lda #0
adc t_24
sta t_24
Calculating one of the shifted versions takes 32 cycles:
Code:
lda t_0
asl a
sta tshl1_0
lda t_8
rol a
sta tshl1_8
lda t_16
rol a
sta tshl2_16
lda t_24
rol a
sta tshl2_24
rainwarrior wrote:
tepples wrote:
Or is this a moot point because of undefined behavior involving t>>(4-(1^7&(t>>19)))?
Since when does "undefined" mean "unimplementable"?

"Crowd" is defined by a C program, but C doesn't define what negative shift amounts or shift amounts greater than the size in bits of the left operand do. At t == 0x200000 samples (around 43 minutes 41 seconds), for instance, this particular sub-expression reduces to
Code:
0x200000>>(4-(1^7&(0x200000>>19)))
0x200000>>(4-(1^7&(4)))
0x200000>>(4-(1^4))
0x200000>>(4-5))
One might consider defining the piece to end at the first undefined behavior. But in C,
undefined behavior causes time travel:
The C committee wrote:
However, if any such execution contains an undefined operation, this International Standard places no requirement on the implementation executing that program with that input (not even with regard to operations preceding the first undefined operation).