Quickest code....

[Galahad/FLT]

Is the following quicker in a loop

move.w d1,(a0)
addq.w #4,a0

or is

move.l d1,(a0)+

this is for 68000.

[Pat the Cat]

I could be wrong, think it depends partly on what kind of RAM it's running in. Also how many bitplanes are being displayed.

Technically, the second is moving more data. The first only moves a word, and increments the counter by +4.

Are you sure these two bits of code are doing the same thing? Doesn't look like it from here..

[Galahad/FLT]

Originally Posted by Pat the Cat

I could be wrong, think it depends partly on what kind of RAM it's running in. Also how many bitplanes are being displayed.

Technically, the second is moving more data. The first only moves a word, and increments the counter by +4.

Are you sure these two bits of code are doing the same thing? Doesn't look like it from here..

If I hadn't missed out the + on the end of the second code example then yes it would have been the same

first code is moving just the word colour value into a copperlist, and then skipping colour register word to get to the next colour value.

the second code would have the colorregister and colour value all in one in the data register, and a straight longword move with no need to add anything to A0 because by using (a0)+, its already at the next correct location.

So folks, i'm under the impression using words is quicker on 68000, but is that the case with this code?

[Pat the Cat]

Looks like it, according to;-

http://oldwww.nvg.ntnu.no/amiga/MC68...000timing.HTML

Longwords take twice as long to write, as the the data bus is only 16 bits wide on a 68000 - so it has to happen twice. Wheras the addq.4 to an address is done very quickly, quicker than writing a word to a memory address. Although the second write, to write a long word, is going to slow things down some. Shouldn't it be addq.2, to increment the address pointer?

Like I said, it does depend to a certain extent on where the code runs - it's not called "fast" RAM for nothing.

The HRM explains those issues, with bus contention in chip RAM, a lot more clearly than I can.

[Galahad/FLT]

Originally Posted by Pat the Cat

Looks like it, according to;-

http://oldwww.nvg.ntnu.no/amiga/MC68...000timing.HTML

Longwords take twice as long to write, as the the data bus is only 16 bits wide on a 68000 - so it has to happen twice. Wheras the addq.4 to an address is done very quickly, quicker than writing a word to a memory address. Although the second write, to write a long word, is going to slow things down some. Shouldn't it be addq.2, to increment the address pointer?

Like I said, it does depend to a certain extent on where the code runs - it's not called "fast" RAM for nothing.

The HRM explains those issues, with bus contention in chip RAM, a lot more clearly than I can.

As i'm sure you're aware, copperlists can only reside in chip mem

[Toni Wilen]

move.w dn,(an) takes 8 cycles (prefetch and write)
addaq #x,an (both word or long) is 8 cycles. (prefetch and idle)

move.l dn,(an)+ takes 12 cycles (two writes and prefetch)

Because both variants have same beginning cycle usage (3 back to back memory accesses), move.l can never be slower, even if DMA steals cycles.

[Galahad/FLT]

Originally Posted by Toni Wilen

move.w dn,(an) takes 8 cycles (prefetch and write)
addaq #x,an (both word or long) is 8 cycles. (prefetch and idle)

move.l dn,(an)+ takes 12 cycles (two writes and prefetch)

Because both variants have same beginning cycle usage (3 back to back memory accesses), move.l can never be slower, even if DMA steals cycles.

Lovely......

Toni is of course right.

testet this:

rept 8000
move.w d1,(a0)
addq.w #4,a0
endr

and

rept 8000
move.l d1,(a0)+
endr

and the later was about 16 scanlines faster.

even with 6 bitplane DMA, the later is still faster. funny, as i would have thought the first was faster.

[Toni Wilen]

Possible reason for confusion is that addq.w #x,Dn is 4 cycles but addaq.w #x,An is 8 cycles. Address register operations are always long wide which needs more than 1 internal operation (ALU is only 16-bit) and any word values need to be internally sign extended to long first.

[Pat the Cat]

Originally Posted by LaBodilsen

Toni is of course right.

testet this:

rept 8000
move.w d1,(a0)
addq.w #4,a0
endr

and

rept 8000
move.l d1,(a0)+
endr

and the later was about 16 scanlines faster.

even with 6 bitplane DMA, the later is still faster. funny, as i would have thought the first was faster.

Yes, that's the real test... write code that loops lots, and time them.

Turn interlace on, as well as 6 bitplanes (EHB or HAM) and try playing sound at the same time and the CPU crawls if running from code in chip RAM. At least, it always did in my code.

Originally Posted by Toni Wilen

Possible reason for confusion is that addq.w #x,Dn is 4 cycles but addaq.w #x,An is 8 cycles. Address register operations are always long wide which needs more than 1 internal operation (ALU is only 16-bit) and any word values need to be internally sign extended to long first.

Ah... That's where I got tangled.

Because I thought, you can only ADDQ values of 1 to 8 - I thought they translated as seperate opcodes. Which would mean the operation takes place entirely inside the CPU, with no bus access required.

If the CPU has to read the value to be added, that slows down the operation... but... even more...

... Fact remains, to move the same amount of data (word versus longword), you really have to have a second write to the first set of code anyway!

[Toni Wilen]

Originally Posted by Pat the Cat

Yes, that's the real test... write code that loops lots, and time them.

This is now "basic" knowledge and practically fully known, there is no need for testing anymore

Because I thought, you can only ADDQ values of 1 to 8 - I thought they translated as seperate opcodes. Which would mean the operation takes place entirely inside the CPU, with no bus access required.

They are separate opcodes. (add.w #x,An is even slower due to extra memory read). Answer is still the same: 68000 is internally 16-bit, 32-bit operations mean multiple 16-bit operations.