AmigaOS 4 68K emulation options

Currently any AmigaOS 4 system is capable of emulating system-friendly 68K programs via either the interpretative or JIT emulation layers. Both present the system with as having a 68020 with a 68881/2 FPU. Is there any way to change that? Can the system appear to a program to be a 68000? Or a 68030? Or to not have an FPU?

-- eliyahu

@eliyahu
Why would you want to do anything like that? For example:
Quote:Not matter if real hardware or emulated, a system without FPU is much slower, without adding any compatibility to ancient, broken software which can only work with something like UAE or Fellow. but not on AmigaOS 4.x, nor AmigaOS 3.x with a gfx card.
Emulating "more" than a 68030/68882? Why? All newer CPUs (68040, 68060) have less features and would be even slower, if they wouldn't have higher CPU clock frequencies and some additional super-scalar features on real hardware.
Not only slower, but less accurate as well. At least about 20 years ago when I ported it to AmigaOS the newlib soft-float test suite still used the results of a real 68882 FPU to report rounding errors of the implementation. No common CPU of that time, neither DEC Alpha, HP PA-RISC, IBM/Motorola/Freescale POWER/PowerPC, AMD x64, Intel x86 and XEON, MIPS, BBC/Acorn/Arm Ltd./Samsung/Huawei/etc. (Strong)ARM, nor anything else, was able to get results even close to the ones of the 80 bit 68881/2 FPU.
Additionally the clock frequency of the emulated CPU is completely irrelevant for any system with a faster host CPU than the emulated guest one...
Any "system friendly" software will work on any m68k CPU, on any gfx hardware (OCS/ECS/AGA/gfx card), no mater if real or emulated. If it doesn't it's not system friendly at all and may require ugly hacks like NallePuh or NewMode.

@joergQuote:

No, because (correct me if I'm wrong) for example 68k emu in AOS4 or MOS for speed reasons (correct me if I'm wrong) does not make sure that instructions that are atomic on real 68k hw, are atomic in emulation as well.

Software will work or appear to work because there's not many Amiga system friendly software that depends in a hard way (like crashing if atomic stuff not guaranteed) on atomic stuff.

But I guess for example a 68k compiled webkit based web browser would not run fine in AOS4 (or MOS) 68k emulation. Despite being "system friendly" software. Or would it?

@joerg

Perhaps because some demos and program check what CPU you have, and refuse to start if you do not have 040 or 060 CPU.

@Georg

I think your just bring up this problem, because someone pointed it out at some point, do you have any actual example of anything that breaking because of this?

Quote:

it should run just fine. Portable C/C++ code compiled for 680x0 programs written in C/C++ will depend on shampooers or forbid / permit, to make struct or data atomic.

Only stuff optimized with assembler you can have problems with atomic instructions. atomic Instructions do not work on a data structure only one address at the time.

I was curious about example of atomic opcodes, so found a example for PowerPC.
https://www.mulle-kybernetik.com/artik ... zation/opti-4-atomic.html

I guess it can be useful if you keeping record of number of items in list or something, but this instructions won’t be useful for protecting a linked list for example, where you need to maintain a previous and a next pointer.

@Georg
Quote:I built and tested my AmigaOS 3.9/m68k port of OWB on AmigaOS 4.1, I didn't have a 3.x/m68k system at that time any more.
Of course was working on AmigaOS 4.1 without problems, I don't know if it works on MorphOS.

@LiveForItQuote:My AmigaOS 3.9 and 4.x ports of OWB don't have a single line of common code in the system specific parts, but neither one uses Forbid()/Permit() or Disable()/Enable() directly.
For the system specific mutex parts the AmigaOS 4.x ports are using the IExec->Mutex(Attempt|Obtain|Release)() functions, which are based on the PPC atomic instructions. No Forbid() or Disable() involved.
The AmigaOS 3.9 port uses the old exec (Attempt|Obtain|Release)Semaphore() functions instead, which AFAIK are using Forbid()/Permit(), or maybe even Disable()/Enable(), internally.

@eliyahu
IIRC one of the tools of OS4 itself (probably something in C:) can change the reported emulated m68k CPU, not the actual CPU emulation, but I don't remember which one nor with which options.
But there is a tool on os4depot.net as well which should do the same.

@LiveForItQuote:

Simpliest example is probably WFLG_RMBTRAP. Docs say:

---
WFLG_RMBTRAP is an exception to most fields in Intuition structures
because it is legal for an application to directly modify this flag.
Note that this change must take place as an atomic operation so that
Exec cannot perform a task switch in the middle of the change. If you
are unsure your compiler will do this, use a Forbid()/Permit() pair to
prevent a task switch.
---

Most 68k programs using this will have a "or.l" and "and.l" or "bset/bclr" in the exe to change this flag, as this is atomic on 68k. On AOS4 and MOS in their 68k emus this almost certainly will not be executed/emulated atomically. So it can misbehave.

For example theoretically what can happen is that Intuition (input.device task) in the middle of the program's operation gets activated (preempts program task) and wants to change some flag in the window itself, like WFLG_WINDOWACTIVE. This change may be lost/swallowed:

68k program:

"or.l WFLG_RMBTRAP,win_Flags(a0)"

but emulated as ~:

"load win_Flags, ppcreg"
"or WFLG_RMBTRAP, ppcreg"
"store ppcreg, win_flags"

If Intuition (input.device task) preempts program task between the "load" and "store", then later the store will overwrite/ignore/undo whatever Intuition changed in the flags.

Quote:

Maybe older version of browsers/owb/webkit were different (and also relied less on multiple tasks/threads), but nowadays c++ programs (I'm no c++ coder) (and c++ standard libs/featuers!?) seems to be full of things using this std::atomic stuff or lockless algorithms or whatever. And I doubt that for Amiga ports of gcc this would internally all be handled using Forbid()/Permit().

@thread

I had my reasons for asking this, but it looks like there are no parms I can set anywhere. Thanks for your answers.

-- eliyahu

@eliyahu
Quote:If the Set68kcpu tool from OS4depot.net doesn't help for what you are trying to do you have to be more specific on what you want to achieve.

@LiveForIt

Yeah that's true.It happened me sometimes.And with some games too.

But with 68030 you must go very well on an Amiga 1200 or Amiga 1300.

@Georg

I think that depends on internal handling of messages in AmigaOS4.x as well, if its safe or if it’s not.
not just if supports atomic or not.

Perhaps that’s something that should have a setter function, I was looking for function to set it, the other day, as know about ModifyIDCMP() function.

there is a queue of message some that might not have been yet processed, and some might be added to queue while the messages are processed. What happens to the messages in queue, waiting to be processed? After FLAG was modified. As they lost too?

@joerg

That's perfect! That's all I needed. Thank you very much for the link.

-- eliyahu