Use of MOVE16

[SpeedGeek]

Originally Posted by Thomas Richter

Last but not least, let me mention that while MOVE16 is a instruction that is supported by the 68060 (and 68040), the Amiga bus system cannot be in general expected to support it, so it is typically not safe to use on an Amiga.

Well, thanks for taking the time to acquire a comprehensive and detailed knowledge of the 040/060 unimplemented instructions. Now, if you had only taken a fraction of this time to understand that the Amiga hardware bus design either does not support burst at all on 68000-68020 systems or only optionally supports burst on 68030+ systems (and only for part of the available address space on the bus) then I would not need to repeatedly reply to this topic (again)...

Now, since the 040 and 060 also optionally support burst they can and do function (with some hardware adaptations) on any classic Amiga 68K bus system.

Hence, MOVE16 has absolutely no compatibility problem with the Amiga 68K bus.

Thus, the principle concerns with MOVE16 "Safe Usage" are 1) The 16 byte source and destination alignment requirement and 2) The Motorola/Freescale documented Errata conditions. But this should be a comparatively simple problem to solve any for any Software developer making such extraordinary efforts as described above.


*****************

Mod note: Some posts moved to a new thread from: http://eab.abime.net/showthread.php?t=102568

[AmigaHope]

I've never had any problem using MOVE16, ever. It either operates quickly on cached writes or stalls the CPU while the writes happen on uncached memory and at least saves instruction loads on word-length operations while it's doing it.

[Thomas Richter]

Originally Posted by SpeedGeek

Now, since the 040 and 060 also optionally support burst they can and do function (with some hardware adaptations) on any classic Amiga 68K bus system.

Hence, MOVE16 has absolutely no compatibility problem with the Amiga 68K bus.

No, and no again. Once again: MOVE16 bursts always, even on non-cachable data, even on data that goes over the Zorro bus. Which means that there need to be logic on the board that disables bursting to go through Zorro. Which may or may not be the case - you cannot in general assume that the hardware fixes a software configuration issue for you.

[SpeedGeek]

Originally Posted by Thomas Richter

No, and no again. Once again: MOVE16 bursts always, even on non-cachable data, even on data that goes over the Zorro bus. Which means that there need to be logic on the board that disables bursting to go through Zorro. Which may or may not be the case - you cannot in general assume that the hardware fixes a software configuration issue for you.

Yes and yes again! You still have not realized that the Motorola/Freescale Errata and addendum info also applies to documentation errors (not just CPU mask set bugs). Unfortunately, the M68K programmers reference manual error was not corrected so I will correct it now.

ERROR (M68K PRM):
"Line transfers are performed using burst reads and writes, which begin with the long word pointed to by the effective address of the source and destination, respectively. An address register used in the post increment addressing mode is incremented by 16 after the transfer."

CORRECTION:
"Line transfers are optionally performed using burst reads and writes, which begin with the long word pointed to by the effective address of the source and destination, respectively. An address register used in the post increment addressing mode is incremented by 16 after the transfer."

REFERENCE (M68040 Users Manual):
"5.4.6 Transfer Burst Inhibit (TBI)
This input signal indicates to the processor that the accessed device cannot support burst mode accesses and that the requested line transfer should be divided into individual longword transfers. Asserting TBI with TA terminates the first data transfer of a line access, which causes the processor to terminate the burst and access the remaining data for the line as three successive long-word transfers. During alternate bus master accesses, the M68040 samples the TBI to detect completion of each bus transfer."

BTW, my trusty Commodore A3640 has never run a burst cycle since burst is permanently disabled on this card.

[Thomas Richter]

Originally Posted by SpeedGeek

Yes and yes again! You still have not realized that the Motorola/Freescale Errata and addendum info also applies to documentation errors (not just CPU mask set bugs). Unfortunately, the M68K programmers reference manual error was not corrected so I will corrected it now.

*Sigh* This is the additional logic that is required to disable burst transfers. However, as stated, it is missing on *some* rare boards, and thus you cannot rely on MOVE16 not attempting to burst. Not that I'm telling this the first time.

[SpeedGeek]

Originally Posted by Thomas Richter

*Sigh* This is the additional logic that is required to disable burst transfers. However, as stated, it is missing on *some* rare boards, and thus you cannot rely on MOVE16 not attempting to burst. Not that I'm telling this the first time.

** SIGH **
Please specify examples rather than claiming such "Rare" Boards exist. Any 040 or 060 Board with missing /TBI logic is faulty, defective and non-functional. Such a board will fail in early exec when the instruction cache is enabled. The instruction cache also optionally uses burst for line transfers but the Kickstart ROM controllers Gary, Fat Gary and Gale do not support burst.

[Thomas Richter]

Originally Posted by SpeedGeek

** SIGH **
Please specify examples rather than claiming such "Rare" Boards exist. Any 040 or 060 Board with missing /TBI logic is faulty, defective and non-functional. Such a board will fail in early exec when the instruction cache is enabled. The instruction cache also optionally uses burst for line transfers but the Kickstart ROM controllers Gary, Fat Gary and Gale do not support burst.

I already gave examples. You just decided to ignore them. Early GVP boards for the A2000 had this problem, and such boards can boot and work perfectly fine under a number of circumstances.


Kickstart startup disables caching in the 1st 16MB, thus for all of Zorro-II devices, the kickstart itself, and chipmem, and enable caching for 32-bit RAM on board. Combine that with a custom 68040.library that keeps caching disabled in the Zorro-area, and the board boots and works fine. Expansion RAM in the Zorro-II region would remain non-cachable, and slow, but it is slow anyhow, and the board would use the 32-bit RAM on board outside the 24-bit area.


Not that I haven't mentioned this before. MOVE16 is *not* a recommended option, same as TAS, CAS and CAS2. It *may* appear to work in many circumstances, but not reliably on all boards in all circumstances.

[AmigaHope]

Sounds like there'd be a market in fixing these boards to add burst inhibit. Just some GALs piggbacked on that assert the line when it snoops an address matching chip and zorro space.

[SpeedGeek]

Originally Posted by Thomas Richter

I already gave examples. You just decided to ignore them. Early GVP boards for the A2000 had this problem, and such boards can boot and work perfectly fine under a number of circumstances.


Kickstart startup disables caching in the 1st 16MB, thus for all of Zorro-II devices, the kickstart itself, and chipmem, and enable caching for 32-bit RAM on board. Combine that with a custom 68040.library that keeps caching disabled in the Zorro-area, and the board boots and works fine. Expansion RAM in the Zorro-II region would remain non-cachable, and slow, but it is slow anyhow, and the board would use the 32-bit RAM on board outside the 24-bit area.

Not that I haven't mentioned this before. MOVE16 is *not* a recommended option, same as TAS, CAS and CAS2. It *may* appear to work in many circumstances, but not reliably on all boards in all circumstances.

I searched the Amiga hardware sites, EAB and Amiga.org, Aminet and comp.sys.amiga.hardware and found nothing about an early GVP 040 Board for the A2000 as you have described ("Broken by Design").

Assuming such a Board actually ever did exist, it was probably a prototype or developer Board with only a small number of such Boards ever produced. exec only disables the cache temporarily (probably for polling the hardware) but the cache is enabled by boot time so this Board would need a special exec.library in addition to the special 68040.library to keep the cache disabled.

Now, for you to go on telling 99.9% of the 040 and 060 users which can use MOVE16 quite reliably it is "Not Recommended" shows just how irrational you really are. You went from "Incompatible with the Bus" to an absurdly exceptional case to attempt to justify your claims. Very sad indeed...

[Thomas Richter]

Originally Posted by SpeedGeek

Now, for you to go on telling 99.9% of the 040 and 060 users which can use MOVE16 quite reliably it is "Not Recommended" shows just how irrational you really are. You went from "Incompatible with the Bus" to an absurdly exceptional case to attempt to justify your claims. Very sad indeed...

Yes, it's so irrational to create software that just works. I know. If you are ok with "works most of the time", well... very sad indeed. I don't.

[SpeedGeek]

Originally Posted by Thomas Richter

Yes, it's so irrational to create software that just works. I know. If you are ok with "works most of the time", well... very sad indeed. I don't.

Yes, there is indeed a lot of Software that just works most of the time (or only some of the time):

- 68020+ dependent Software
- 68K FPU dependent Software
- 68K MMU dependent Software
- 68000 dependent Software
- 7 MHz dependent Software
- Chip RAM size dependent Software
- Fast RAM size dependent Software
- ECS chip set dependent Software
- AGA chip set dependent Software
- Amiga OS version dependent Software
- 3rd party Hardware dependent Software (Including "Broken by Design" Software workarounds)

etc., etc. and so on...

[Thomas Richter]

Originally Posted by SpeedGeek

Yes, there is indeed a lot of Software that just works most of the time (or only some of the time):

- 68020+ dependent Software
- 68K FPU dependent Software
- 68K MMU dependent Software

There are two approaches for this: The recommended variant would be to use an internal dispatcher for an optimized version if an advanced CPU is dependent such that there is only a common binary for the user. I would discourage the common practise of software compiled for the 68020+ that just crashes, or have separate versions per CPU. The same goes for the FPU variant. Unless speed dependent, the system math libraries solve the problem in the correct way: Transparent to the user. For the MMU, there is a MMU and CPU indepdent solution that takes the internal dispatcher version. Just one version for the user, plus an error message if the resource is not available. But no crash.



None of that can be applied easily to MOVE16 since you cannot so easily determine whether the instruction is robust.

Originally Posted by SpeedGeek

- 68000 dependent Software
- 7 MHz dependent Software

Both bad programming practise and certainly discouraged. To abstract from 68K idiocracies, CBM already added GetCC() to exec. To abstract from the 7Mhz clock, we have the timer.device, or - failing that - custom chip or CIA accesses with guaranteed timing.

Originally Posted by SpeedGeek

- Chip RAM size dependent Software
- Fast RAM size dependent Software

If the software runs out of resources, recommended practise is to abort the program with an error message, but not to crash by using a non-robust instruction. So the situation is not quite comparable. A program must always handle resource problems gracefully.

Originally Posted by SpeedGeek

- ECS chip set dependent Software
- AGA chip set dependent Software

For that, we have the display info database in graphics, BestModeID() and ASL screen mode requesters. Use them. The Os does.

Originally Posted by SpeedGeek

- Amiga OS version dependent Software

For that, we have version checks and a version information in libraries and devices. Otherwise, see "resource exhaustion". There is quite a difference if a program aborts with an error requester if the necessary library version is not available, or crashes due to a hardware conflict you cannot easily test for.

Originally Posted by SpeedGeek

- 3rd party Hardware dependent Software (Including "Broken by Design" Software workarounds)

For that, we have expansion, autoconf and the configdev structure. Programs can safely abort if a necessary resource for its operation is not availble, but do not crash the user. So it is easy to check and easy to react on.



The problem with MOVE16 is that is not so easy to detect error situations (though you may). The "best effort" approach would be to include an internal dispatcher in the software to two implementations (with and without MOVE16), and include an upfront test to test whether it works reliable. I am not sure whether the latter can be made working reliably. I am not even clear whether there is much of a practical advantage for MOVE16 in realistic scenarious.

[SpeedGeek]

Originally Posted by Thomas Richter

None of that can be applied easily to MOVE16 since you cannot so easily determine whether the instruction is robust.

Yes, you can. Please read the 040 manual. MOVE16 "Efficiently" moves large blocks of memory when the data is not expected to be of immediate use.

Since MOVE16 always uses the cache "WriteThrough" policy it's performance is never affected by the worst case of the Copyback mode. If you want to see this "Worst Case" performance try using the AIBB memory test on any 040+ system with the data cache enabled and then disabled.

Originally Posted by Thomas Richter

There is quite a difference if a program aborts with an error requester if the necessary library version is not available, or crashes due to a hardware conflict you cannot easily test for.

The only possible hardware conflict for MOVE16 would be the extremely rare "Broken by Design" early 040 Boards you claim exist... and such Boards would also fail when the cache is enabled without special precautions being taken to prevent this.

Originally Posted by Thomas Richter

The problem with MOVE16 is that is not so easy to detect error situations (though you may). The "best effort" approach would be to include an internal dispatcher in the software to two implementations (with and without MOVE16), and include an upfront test to test whether it works reliable. I am not sure whether the latter can be made working reliably. I am not even clear whether there is much of a practical advantage for MOVE16 in realistic scenarious.

If MOVE16 is safely implemented (as I've already explained above) then there will be no error situations. MOVE16 will not be advantageous for small memory block transfers of Fast RAM (this is when the Best case of the Copyback cache gives MOVE.L the performance advantage). However, if the target memory is known to be non-cachable (e.g. Chip RAM) or Cache WriteThrough RAM (e.g. MMU table RAM) then MOVE16 will always outperform MOVE.L for any block size.

[Thomas Richter]

Originally Posted by SpeedGeek

Yes, you can. Please read the 040 manual. MOVE16 "Efficiently" moves large blocks of memory when the data is not expected to be of immediate use.

This is what this entire debate is all about. No, you cannot, in general, assume that MOVE16 performs correctly in an Amiga system. That is the whole point. The "precautions" on such boards are just "use the vendor supplied CPU library", and you are good.

Originally Posted by SpeedGeek

However, if the target memory is known to be non-cachable (e.g. Chip RAM) or Cache WriteThrough RAM (e.g. MMU table RAM) then MOVE16 will always outperform MOVE.L for any block size.

Why would it? The output would be transfer-burst inhibited anyhow if the board supplies TBI, and thus the net speed result is absent as a MOVEM would deposit the data in the push buffer as well. In fact, on my GVP040 board a MOVE16 into graphics card memory was a bit slower than a MOVEM loop, and on my 2060, the performance of a MOVEM loop into such memory is identical to that of a MOVE16 loop, except that the latter is not necessarily robust.


In my experience, there is nothing to be gained from MOVE16 except potential instabilities. The only case where you might gain something is if you move from CPU-local (32-bit) memory into itself, thus essentially CopyMemQuick(). The best approach here is, however, not to move data around in first place, i.e. use a better algorithm.



If the data cannot be deposited in the right target buffer, for example due to DMA restrictions, or specialized hardware (graphics boards), then the advantage of MOVE16 diminishes anyhow as you run into the issue how to reach "this other data" over a Zorro II/III bus which does not support bursting.

[SpeedGeek]

Originally Posted by Thomas Richter

This is what this entire debate is all about. No, you cannot, in general, assume that MOVE16 performs correctly in an Amiga system. That is the whole point. The "precautions" on such boards are just "use the vendor supplied CPU library", and you are good.

Yes, you can assume MOVE16 is safe to use on properly designed Boards in any classic Amiga 68K system ...and so far it is only you claiming such "Broken by Design" Boards actually exist. The Commodore 68040.library was used verbatim by most 3rd party 68040 Board manufacturers. Phase 5 created their own 68040.library to add support for proprietary hardware, but not because they needed to fix any "Broken by Design" Boards.

Originally Posted by Thomas Richter

Why would it? The output would be transfer-burst inhibited anyhow if the board supplies TBI, and thus the net speed result is absent as a MOVEM would deposit the data in the push buffer as well. In fact, on my GVP040 board a MOVE16 into graphics card memory was a bit slower than a MOVEM loop, and on my 2060, the performance of a MOVEM loop into such memory is identical to that of a MOVE16 loop, except that the latter is not necessarily robust.

Because MOVE16 moves 4 long words per instruction and this is faster than 4 sequential MOVE.L instructions. MOVE.M does not move memory to memory operands so you would need 2 sequential MOVE.M instructions. Also, according to the 040 manual MOVE16 only bypasses the Copyback cache, so how do you conclude it also bypasses the push buffer?

BTW, burst support only affects memory transfer rates but does affect the specific performance benefits of the MOVE16 instruction itself.

Originally Posted by Thomas Richter

In my experience, there is nothing to be gained from MOVE16 except potential instabilities. The only case where you might gain something is if you move from CPU-local (32-bit) memory into itself, thus essentially CopyMemQuick(). The best approach here is, however, not to move data around in first place, i.e. use a better algorithm.

If the data cannot be deposited in the right target buffer, for example due to DMA restrictions, or specialized hardware (graphics boards), then the advantage of MOVE16 diminishes anyhow as you run into the issue how to reach "this other data" over a Zorro II/III bus which does not support bursting.

The obvious problem here is your assumption of "Potential Instabilities" with MOVE16. However, you did not worry a bit about the "Potential Instabilities" of the 060 "Imprecise" mode for Chip RAM... and then when you could not observe any such instabilities, you quickly concluded they don't exist. If only you had used the very same approach with MOVE16.

I just explained two ways in which MOVE16 outperforms other instructions. I even explained an easy way for you to observe the worst case performance of the Copyback cache. So, if you still stubbornly refuse to get it, than any further discussion is pointless.

Originally Posted by coldacid

Hey SpeedGeek and Thomas, this is an interesting conversation, but it's not really relevant to this thread. Perhaps you can continue this discussion in its own?

I agree this is off topic but a moderator would have to create the new thread and move the posts. So you should probably PM a moderator for assistance.

[Thomas Richter]

Originally Posted by SpeedGeek

Yes, you can assume MOVE16 is safe to use on properly designed Boards in any classic Amiga 68K system.

I don't know what "you" assume, but what "one" can assume is probably better left to other people.

Originally Posted by SpeedGeek

The Commodore 68040.library was used verbatim by most 3rd party 68040 Board manufacturers. Phase 5 created their own 68040.library to add support for proprietary hardware, but not because they needed to fix any "Broken by Design" Boards.

GVP had their own library, Apollo had their own library, to name two comtemporary hardware vendors. P5 you already mentioned.



I would really wish there would be a generic way how to supply a CPU library, and I am really trying hard to make the best possible approximation of such a thing, but the reality tells another story, much to my own displeasure. I wish it would be different, but it isn't.

Originally Posted by SpeedGeek

Also, according to the 040 manual MOVE16 only bypasses the Copyback cache, so how do you conclude it also bypasses the push buffer?

It doesn't. It is just not any faster in situations where it matters because the weakest link in the whole affair is the bus, and not the execution speed. The limiting factor is the bus speed, not the execution speed - proven by experiment.


The only situation where it would make a difference speedwise is if you would move from CPU-local 32-bit memory to itself. Unfortunately, the whole architecture of the Amiga makes it impossible to detect whether a particular piece of memory satisfies this requirement, and hence whether MOVE16 is beneficial. Worst, in most situations where you *would* want to move memory around, you want to move it from CPU-local memory over Zorro II/III or the chip mem Bus, and this is exactly the situation where MOVE16 has no benefits because the bus is saturated anyhow, and where it has risks, so you would want to avoid to use it.


Thus, there is rarely any practical gain, except in benchmarks, just risks that cannot be controlled properly because the system does not provide any means to control them.

Originally Posted by SpeedGeek

I just explained two ways in which MOVE16 outperforms other instructions. I even explained an easy way for you to observe the worst case performance of the Copyback cache.

Just that my practical experiments showed that it does not. So why should I bother taking a risk if the net benefit is nil when I would need it?

[AmigaHope]

My 2 cents:

Whenever I had to duplicate a chunk of memory for some reason (e.g. create a backup buffer of "original data" when I'm going to modify the original) as long as the data was bigger than the data cache, MOVE16 was always a win. It was also a (very small) win if I had to copy an image buffer into display memory.

The two cards I own are an A3640 and a CSPPC/060. I never had any problems. C= and Phase 5 represent the #1 and #2 040/060 cards out on the market, probably the large majority. If a tool works well for the vast majority of what's out there, why not use it?

The only thing that would make me think twice would be if any of the #3 cards (Apollo?) had a problem.

It's a tool that definitely works well for what it's intended to do. If it causes problems on some very early 040 cards, well, then they can run a MOVE16-clean version of whatever is created.

It would be interesting if a test program could be created to see if there's a problem on any of the very early cards from RCS, PPI, GVP, etc. I know that PPI included a jumper on the Mercury that sets the burst inhibit on all off-card addresses.

[Thomas Richter]

Originally Posted by AmigaHope

The two cards I own are an A3640 and a CSPPC/060. I never had any problems. C= and Phase 5 represent the #1 and #2 040/060 cards out on the market, probably the large majority. If a tool works well for the vast majority of what's out there, why not use it?

There is a difference between "I am using it for my own fun on my own hardware" and "I want to provide software for others with wide applicability". As long as this is "for me for fun", do what you like, it does not matter whether it breaks on somebody else's machine, his problem. As soon as you create system software (such as an operating system) it becomes your problem whether the software you provide runs correctly as it may damage other people's installations. Then don't.

Frankly, over the last 30 years of Amiga progamming, I had more than enough problems with incompetent third party patches, creating problems on *my* side as a developer causing failures of my software, and I would prefer if authors would be a bit more conservative with programs they provide to the public. In case of failure, it really troublesome and anyoing to hunt down somebody else's bugs.

[SpeedGeek]

Aminet Move16 Benchmark update (SpeedGeek 2020)

The old Move16v2 Benchmark from Aminet was updated
as follows:

- Removed all NOPs from MOVE16 loop code (The author was
probably using either a really old version of 68040.library
or an early XC68040 mask set CPU if he believed these NOPs
were actually needed).

- Applied PatchFor020 (Yes, the SAS Crap compiler still
generates standard 68000 maths even for 020+ compiled code)

Here are some benchmark results from my A3000 + A3640
@ 40 MHz system:


**FAST TO FAST**
MoveMem = 1.5800 secs
MoveMem16 = 1.0400 secs
**Fast to CHIP**
MoveMem = 2.7600 secs
MoveMem16 = 2.0800 secs
**CHIP to Fast**
MoveMem = 3.2800 secs
MoveMem16 = 2.1000 secs
**CHIP to CHIP**
MoveMem = 2.9200 secs
MoveMem16 = 2.8800 secs

NOTES:
This Benchmark uses a large block size which means MOVE16 will
always be faster than MOVE.L. Someone who is skilled with
the SAS Crap compiler could recompile it with a smaller block
size (e.g. < Data cache size) to demonstrate when MOVE.L may
be faster. Enjoy!

[AmigaHope]

Originally Posted by Thomas Richter

There is a difference between "I am using it for my own fun on my own hardware" and "I want to provide software for others with wide applicability". As long as this is "for me for fun", do what you like, it does not matter whether it breaks on somebody else's machine, his problem. As soon as you create system software (such as an operating system) it becomes your problem whether the software you provide runs correctly as it may damage other people's installations. Then don't.

Frankly, over the last 30 years of Amiga progamming, I had more than enough problems with incompetent third party patches, creating problems on *my* side as a developer causing failures of my software, and I would prefer if authors would be a bit more conservative with programs they provide to the public. In case of failure, it really troublesome and anyoing to hunt down somebody else's bugs.

Look, I get where you're coming from. There may well be some very early 68040 cards that do not set burst inhibit properly and instead rely entirely on cache control to avoid burst. This is a broken design, but whatever, they exist.

Having released code just not work with no explanation or no idea where the problem is coming from would be very aggravating.

But by that same argument we should never use EHB mode because EHB didn't exist on the early NTSC A1000s.

My argument is that the number of cards without burst inhibit are very small, and that's not reason not to use faster code just because some can't use it. Instead just leave an optional setting for people who have these cards to use slower code.

It's not the responsibility of the coder to always nerf his code because there's a small number of systems with a broken design.