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).