data/intruction burst 68030

[Wepl]

what happens when data/instruction burst is enabled in the cacr and the hardware doesn't support it. is there any drawback?

[meynaf]

So far i've never seen any drawback like this. AFAIK if it's not supported, well, you just won't have it.

Instruction burst is always safe IMO.
But data burst has some drawbacks and i wouldn't recommend enabling it (it slows down random accesses).

[Gunnar]

Originally Posted by meynaf

But data burst has some drawbacks and i wouldn't recommend enabling it (it slows down random accesses).

Why should it slow down random access?

[SpeedGeek]

Originally Posted by Wepl

what happens when data/instruction burst is enabled in the cacr and the hardware doesn't support it. is there any drawback?

If the hardware doesn't support it then burst mode enabled has no drawback. It simply means the CPU will REQUEST a burst cycle but it's always up to the hardware to ACKNOWLEDGE the burst cycle.

Originally Posted by Gunnar

Why should it slow down random access?

In practice the CPU doesn't randomly access memory but may appear to do so at times. The term "Random" most often refers to a non-sequential memory access. The burst cycle obtains it's "Best Case" performance when operands are sequentially accessed and it's "Worst Case" performance when operands are non-sequentially accessed.

Since most instruction operands are sequential within memory the instruction burst "Best Cases" occur much more often then the "Worst Cases". However, since data operands are often non-sequential or fragmented with memory the data burst "Worst Cases" are often equal to or greater than the "Best Cases".

[Gunnar]

The 68030 has just 16 cache lines. Each cache line has a width of 16 bytes.

If you disallow bursting then the 68030 will need up to twice as long to fill the cache line.

IMHO bursting should always be enabled as it will speed up all common cases.


The question was whether brusting can even slow down the uncommon pointer chase case or not.
I don't recall whethe rthe 68030 does wrapping line burst and early providing of the 1st result.
If it does this then bursting random access data would have no significant drawback
as the data is available to the CPU early and rest of the line would be loaded in parallel.

Can someone qualify this? Does the 68030 line wrap?

[Wepl]

thanks for the info.
I will then enable only the instruction burst.
is there a list of hardware which supports burst transfers?
AFAIK none of the older boards supports it.
aca123x yes
blizzard1230 ?

[Thorham]

Originally Posted by Gunnar

IMHO bursting should always be enabled as it will speed up all common cases.

I always have data burst off on my Blizzard 1230 IV, because having it on can cause problems. LZX unpacking can go wrong (errors with valid archives), and some other issues.

[Kalms]

On 030, if dburst is off then the CPU will not fetch entire cachelines, it only does the necessary memreads. Therefore random pointer walks are faster with dburst off on 030.

When dburst is on, the 030 cache does early providing of the 1st result. I do not know for sure but I think it does linewrap.

Blizzard 1230 supports dburst.

[meynaf]

Originally Posted by Gunnar

The 68030 has just 16 cache lines. Each cache line has a width of 16 bytes.

If you disallow bursting then the 68030 will need up to twice as long to fill the cache line.

But the 68030 will not try to fill the whole cache line with dburst off. It will just access your current data and put that in the cache.

Originally Posted by Gunnar

Can someone qualify this? Does the 68030 line wrap?

What is sure is that there is a measurable slowdown when you do random accesses that are not in the cache, when data burst is on.

[Gunnar]

Originally Posted by Gunnar;

If you disallow bursting then the 68030 will need up to twice as long to fill the cache line

Originally Posted by meynaf

But the 68030 will not try to fill the whole cache line with dburst off. It will just access your current data and put that in the cache.

This is clear and this was my point.
When you disable the burst you only fetch 4byte in your 16byte line and the other 12 byte of cache are unused.

But when the CPU will access another word in the cache line it will have to fetch this word. And this will be slower than with burst enabled.

This means by disabling burst you slow down all routines which work with data that has more than 1 word per cache line.
E.g jpeg decoding, gif display, HTML decoding, memcopy, typical RTG graphic operations, stack operations, .. Matrix mul...

[hooverphonique]

read this: http://amigadev.elowar.com/read/ADCD.../node0161.html

[Gunnar]

Originally Posted by hooverphonique

read this: http://amigadev.elowar.com/read/ADCD.../node0161.html

Yep this reminds of 2 design issues of the 68030 cache is and how problematic using it in an AMIGA is to...

[meynaf]

Originally Posted by Gunnar

This is clear and this was my point.
When you disable the burst you only fetch 4byte in your 16byte line and the other 12 byte of cache are unused.

But when the CPU will access another word in the cache line it will have to fetch this word. And this will be slower than with burst enabled.

This means by disabling burst you slow down all routines which work with data that has more than 1 word per cache line.
E.g jpeg decoding, gif display, HTML decoding, memcopy, typical RTG graphic operations, stack operations, .. Matrix mul...

The difference in access times isn't very big : accessing two separate longwords is still faster than bursting a whole line, and therefore you have to access 3 longwords, if not 4, for the burst mode to become faster.

Tests have shown that many apps run slightly faster with dburst off, and only things like copymem are faster with dburst - but the difference is minimalistic in both cases, so it's not very important.

Originally Posted by Gunnar

Yep this reminds of 2 design issues of the 68030 cache is and how problematic using it in an AMIGA is to...

Using a 68030 in an Amiga isn't very problematic for me. It really has much less problems than 68040/68060.