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