@MEGA_RJ_MICAL


It pleases me profoundly that you are talking to me in a serious way besides of your satirical manner in general.
Thank you I feel very honored.

Anyway.. we all are here because we love the Amiga Concept. And there should be some Light at the End of the Tunnel.

I only tried to inspire based on my little Computer knowledge.. I have poor Computer Skills.. but I try to contribute something!

Thank you

@QBit

What is the Amiga Concept? Never heard of it before.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@kolla
The Amiga Concept is the fact that all PCs and all Macs are inspired by the Amiga or somhow like an Amiga nowadays!
Quote:

kolla wrote: @QBit What is the Amiga Concept? Never heard of it before.

@QBit

Quote:

QBit wrote: @kolla The Amiga Concept is the fact that all PCs and all Macs are inspired by the Amiga or somhow like an Amiga nowadays! Quote: kolla wrote: @QBit What is the Amiga Concept? Never heard of it before.

That's some industrial strength crack you are smoking....

@QBit

AmigaOS used to take visual inspiration from NeXTStep, but nowadays all inspiration seems to come from (old?) Windows. I suppose the reason is that Amiga users and developers to a very large degree are Windows users. Stocholm syndrome.

I find macOS today to be very much what an NG Amiga should have been.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@Rose

Quote:

Rose wrote: @QBit Quote: QBit wrote: @kolla The Amiga Concept is the fact that all PCs and all Macs are inspired by the Amiga or somhow like an Amiga nowadays! [quote] kolla wrote: @QBit What is the Amiga Concept? Never heard of it before.

That's some industrial strength crack you are smoking....[/quote]

Here some Pancakes for you!

I would suggest you a therapy!

Last edited by QBit on 14-Jan-2022 at 03:52 PM.

@QBit

Sometime around 1994, as I remember, I ran across an advertisement in a Linux magazine for a card that had two 68060s for Pentium beating performance. At the time I thought that it would be cool for the Amiga to have multiple 68k on a system. Now, as has been expressed throughout this thread, an emulated 68k is already very fast in comparison to an actual 1990s Motorola 68k chip. Adding multiple 68k support would break compatibility, which is the main reason for staying 68k in the first place. There is also the possibility that a multicore 68k and AOS would actually be slower than a single 68k due to task scheduling (and having to emulate old 68k stuff to keep the old software running).

If you want a faster than 1990s tech 68k performance today, get a Buffie, a Vampire, or good ol' WinUAE on a fast PC. I have been using WinUAE since I sold my SAM460 lite. It actually feels faster than the SAM (I haven't done benchmarks).

_________________
I sold my SAM460ex lite... waiting for money to buy a Raspberry Pi... or a Classic A1000 with Buffee... or an A1222... and OS4.3 FE update 11

@QBit

Quote:

QBit wrote: I dream of expanding WinUAE to Multicore 680x0 support ...

Wouldn't make sense, even if you would have the programming skills to do this changes to WinUAE, it would not make AOS3.x using it.

Some people had the idea of using Multicore support for UAE to speed up the emulation of the Amiga hardware, but they lacked the knowledge to do it.

Last edited by OneTimer1 on 14-Jan-2022 at 08:12 PM.

@PhantomInterrogative
I am talking about WinUAE.. I am talking about Adding an Option to WinUAE "Experimental Amiga" or "UBER Amiga" or "Amiga that never existed" that doesen't mean that you can't use WinUAE anymore it's just adding an experimental Option to WinUAE"! You would still be able to emulate ALL "Classic" and "existing" Amigas.. I am just using the flexibility of WinUAE as Virtual Machine!
Toni Wilen is already informed!

Last edited by QBit on 14-Jan-2022 at 08:33 PM.
Last edited by QBit on 14-Jan-2022 at 08:31 PM.

@OneTimer1
It would be needed to adapt Amiga OS 3.x to Multicore Support
!

@QBit

Quote:

Toni Wilen is already informed!

And he also deleted your post since it didn't have anything to do with bug reports of new beta which the thread was for.

@PhantomInterrogative

I did... there was a benchmark comparation (I think it was converting a file) and I could beat slower PPC processors with unoptimized 68k. The only models faster was X1000 (or X5000 for sure)

@OneTimer1

multicore works already... just run several instances of winuae

Seriously to have a software Benefit from several core you need OS support (certainly the case) but also you must divide the software in parts that can be executed by different cores. And debugging is especially challenging then. I cannot imagine how a 68k platform really would benefit from that. Even if it would be possible in theorie you still need adapted software and you have no development tools for that. And without adaption software would not be faster than when running on one core.

@Rose

A Pancake for you!

What counts is.. he knows the Idea!

Last edited by QBit on 15-Jan-2022 at 01:11 AM.

Quote:

Rose wrote: And he also deleted your post since it didn't have anything to do with bug reports of new beta which the thread was for.

Friend Rose,
Toni deleted the post in order to keep this precious, revolutionary idea to himself.

"We'll play this one close to the chest" he whispered to QBit in quasi-asmr, holding his shoulders and looking straight into his eyes"

7 years of plenty followed.

_________________
I HAVE ABS OF STEEL
--
CAN YOU SEE ME? CAN YOU HEAR ME? OK FOR WORK

Birbo Quote:

The best solution is (that's just my opinion), how the Apollo CPU from the Vampire Team has been made. Is it Multicore? Yes, I think so. You have different cores doing different stuff, right? This was and is the best Amiga way you can choose. Gunnar von Boehn and the whole Team around the Apollo CPU did an amazing job. It's all we need in this question / discussion: The Apollo CPU.

The Apollo core is single core only. I believe the single core multi-threading additional thread is used like AMP instead of SMP (for blitter emulation using the SIMD unit). Multiple threads on the same core share the core by trading off execution during stalls. Multi-threading usually has more data sharing and more can be assumed about the global (from all cores) order of commitment of executed instructions.

most difficult to support: multi-processor multi-core (with or without multi-threading)
moderately difficult to support: uni-processor multi-core (with or without multi-threading)
simplest to support: uni-processor multi-threading

The AmigaOS already has multi-tasking assumptions that tasks can be pre-emptivly interrupted and switched at any time which need not break with multi-threading swapping of tasks on the same core (sequential consistency is maintained). Multi-core allows multiple cores to execute in parallel rather than sequentially (no sequential consistency between cores other than what the hardware and memory model provides). Most modern multi-core memory models are designed to allow multi-processor multi-core systems where few assumptions are possible as cores and memory may be far away and take many cycles to update (NUMA configuration). The PPC relaxed memory model is one of the weakest from a hardware perspective which was originally thought to provide a significant performance advantage as well as supporting NUMA systems at the cost of more difficult to program multi-core systems. Synchronization instructions like fences and barriers are required to provide sequential synchronization but are error prone when inserted by programmers and can actually decrease performance compared to a more sequential ordering. The only advantage lost with a more sequential ordering and stronger memory model is NUMA support which is not used for even high end personal computers anymore as uni-processor multi-core can provide enough cores for all but the most parallel of computing algorithms. A more sequential memory model is the better choice and older weak memory models chose a poor path.

A more sequential memory model is easier to program.

Mark Batty Quote:

Relaxed-memory concurrency is now mainstream in both hardware and programming languages, but there is little support for the programmer of such systems. In this highly non-deterministic setting, ingrained assumptions like causality or the global view of memory do not hold. It is dangerous to use intuition, specifications are universally unreliable, and testing outcomes are dependent on hardware that is getting more permissive of odd behaviour with each generation. Relaxed-memory concurrency introduces complications that pervade the whole system, from processors, to compilers, programming languages and software. There has been an effort to tame some of the mystery of relaxed-memory systems by applying a range of techniques, from exhaustive testing to mechanised formal specification. These techniques have established mathematical models of hardware architectures like x86, Power and ARM, and programming languages like Java. Formal models of these systems are superior to prose specifications: they are unambiguous, one can prove properties about them, and they can be executed, permitting one to test the model directly. The clarity of these formal models enables precise critical discussion, and has led to the discovery of bugs in processors and, in the case of Java, x86 and Power, in the specifications themselves.

The C11 and C++11 Concurrency Model
https://www.sigplan.org/Awards/Dissertation/2015_batty.pdf

Without order there is chaos and unpredictability. A sequential memory model is the goal of the new C/C++11 multi-core atomic operations.

Mark Batty Quote:

Following earlier C++ design discussions, Boehm and Adve provided a criteria under which programs executed in their relaxed memory model behave according to sequential consistency, and this became a design goal of the C/C++11 memory model: programs that do not have any un-annotated data races, and that avoid using the lowest-level interface to memory, should execute in a sequentially consistent manner. This provides programmers who do not need to use the highest-performance features with an intuitive memory model (for race-free programs). The guarantee went further, stating that races can be calculated in the context of the sequentially-consistent memory model, rather than in the far more complex setting of the relaxed memory model. This is a powerful simplification that allows some programmers to be shielded from the full complexity of the memory model, while experts have access to high-performance features. Although, in early drafts of the C/C++11 standards, this laudable design goal was compromised (details in Chapter 5), the ratified language does provide this guarantee, as we show in Chapter 6.

https://en.cppreference.com/w/c/atomic/memory_order

The C/C++11 multicore atomic operations allow order to be introduced in a portable way but they are still error prone with several choices to define the memory order and it doesn't help the Amiga as existing Amiga programs don't have them. The C/C++11 atomic operations abstract the fence and barrier instructions which the Amiga also doesn't have in existing code.

A more sequential memory model is not necessarily lower performance.

Relaxed or weak memory models were thought to have better performance as more load/store reordering and speculation are allowed but not much research was done initially. Some choices of a more sequential memory ordering can lower performance depending on the core design. New research points to a much lower performance advantage from a relaxed memory model. In the following paper, a new improved relaxed memory model was constructed and evaluated only to find that it was not worthwhile. TSO is Total Store Order which is the more sequential memory model and WMM is the newly constructed relaxed memory model thought to provide improved performance over existing relaxed memory models. The following is the paper summary.

Sizhuo Zhang Quote:

We compared the PPA of WMM and TSO using small out-of-order multiprocessors and benchmarks written using portable multithreaded libraries and compiler built-ins. Our evaluation shows that TSO without store-prefetch has 5.6% average overheads over WMM in single-threaded performance. The overheads are mainly because the slow dequeue of SQ in TSO makes SQ become full and thus stalls register renaming. After introducing store-prefetch to TSO, most of the performance overhead of TSO is eliminated and the average overhead drops to 0.8%. In multithreaded benchmarks with abundant synchronizations, TSO can actually be faster than WMM. For example, in GAP benchmarks, TSO-Base can reduce the execution time of WMM-Base by 4.5% on average, and maximumly by 10%. This is because the frequent fences in WMM serialize load execution while not all the fences are really needed at runtime. TSO processors can easily have loads speculate over fences and thus get better performance as long as the speculation ends up to be successful, i.e., not killed by cache evictions. Although some of these fences may be unnecessary (e.g., because programmers are being conservative to ensure correctness and portability), our experiment shows that removing these unnecessary fences still cannot make WMM outperform TSO. It should be noted that the penalty of fences in WMM may be exacerbated if the processor becomes larger, because a fence can affect more in-flight instructions. The speculative loads in TSO may also become more susceptible to cache evictions, so a predictor may be needed to indicate when to speculate over fences. We do not observe frequent failures of speculative loads possibly because our ROB size is small. It is possible to implement a WMM processor that also let loads speculate over Reconcile fences and monitor cache evictions. However, the condition for when a load is no longer affected by cache evictions in WMM is more complicated than that in TSO. Resorting to a simple condition (e.g., when the load is dequeued from LQ) makes WMM implementation equivalent to a TSO/PSO implementation. Even if a WMM processor allows loads to speculate over Reconcile fences and implements a precise checking logic, it is still unclear whether the WMM processor, which is more complicated than TSO processors in both hardware implementation and software programming, can provide strictly better performance than TSO processors. Our experiment on removing fences in GAP benchmarks implies that speculation over fences in WMM can at most make the performance of WMM equal to, but not better than, that of TSO. As for energy, TSO is almost the same as WMM in terms of the number of mis-speculative loads, DRAM accesses and network traffic between cores and L2. As for area, the area of the core logic of TSO is actually 3% less than that of WMM. That is, we do not observe any benefits of weak memory models in terms of area or energy efficiency. Another observation is about the SI coherence protocol, which can cause the reordering of data-dependent loads. The SI protocol is admitted only by WMM but not TSO. Although the SI protocol is easier to implement and could be more scalable, it does not improve performance or energy consumption. In fact, in multithreaded benchmarks with frequent synchronizations, the SI protocol can degrade performance and cost significantly more energy. For example, in GAP benchmarks, WMM-SI is 12% slower than TSO-Base and generates 100% more network traffic than TSO-Base on average. Weak memory models can have more flexible implementations, but which are not necessarily the better ones. The insignificant difference between TSO and WMM also prompts us to rethink if weak memory models are really necessary.

Constructing and Evaluating Weak Memory Models
https://dspace.mit.edu/bitstream/handle/1721.1/122690/1124763012-MIT.pdf?sequence=1&isAllowed=y

The research was done by creating an OoO multi-core CPU in FPGA more advanced than the Apollo core where changes to the hardware that affected the memory model could be made. The amount of data evaluated is impressive also. The conclusion is good science as it did not support the hope of the researcher to create a new improved relaxed memory model yet he boldly stated the truth. I would look into hiring this man as part of a design and development team if I was in charge. There is other research and educated opinions which hint at a negligible performance advantage for relaxed memory models but they often consider the disadvantage of the difficulty of programming a relaxed memory model more while having less statistics.

Conclusion

SMP while maintaining Amiga compatibility is very difficult even with a more sequential memory model between cores of a uni-processor (UMA which allows for HSA like modern consoles too). Storing to the same memory location from parallel cores at the same time is tricky. Such accesses would need to be arbitrated or a forbid/disable used. Forbid/disable can be a macro on the 68k which practically requires custom hardware help but this is not a problem with Amiga emulation. Suspending and restarting all other cores from a Forbid/Permit Disable/Enable is a kludge which hardware could likely help with but this is inefficient for SMP in all cases. Atomic memory instructions must be globally atomic now to handle cases like ADDQ.W #1,lib_cnt to bump library bases (that is the memory needs to be locked while performing the RMW where other cores attempting the same memory location access would be forced to wait/stall). In theory, it should be possible to get SMP to work with reduced efficiency although I'm not sure it would be worthwhile. A more sequential memory model would require fewer changes to the AmigaOS while breaking compatibility if it was not worthwhile or there is some obstacle I don't foresee. I do feel SMP support is very important to be competitive as a personal computer and much superior to AMP for general purpose computing.

PhantomInterrogative Quote:

Sometime around 1994, as I remember, I ran across an advertisement in a Linux magazine for a card that had two 68060s for Pentium beating performance. At the time I thought that it would be cool for the Amiga to have multiple 68k on a system. Now, as has been expressed throughout this thread, an emulated 68k is already very fast in comparison to an actual 1990s Motorola 68k chip. Adding multiple 68k support would break compatibility, which is the main reason for staying 68k in the first place. There is also the possibility that a multicore 68k and AOS would actually be slower than a single 68k due to task scheduling (and having to emulate old 68k stuff to keep the old software running).

I believe the 68060 already has better performance than the Pentium at the same clock speed.

https://amigaworld.net/modules/newbb/viewtopic.php?topic_id=44391&forum=25#847418

My overclocked 68060@75MHz is beating a Pentium@90MHz in integer performance by 20% (40% at the same clock speed) in the ByteMark benchmark. Frank Wille's vbcc compiled ByteMark benchmark also easily outperforms the Pentium at the same clock speed in integer performance and is nearly on par with the fully pipelined Pentium FPU in floating point performance (much better than the GCC compiled benchmark in FPU performance). The big problems for the 68060 were the lack of clock rating increases and compiler support. The 68060 was the Pentium killer but it couldn't be clocked up or it would have competed with the PPC.

There were more than a few multiprocessor 68k systems. SMP with Amiga compatibility is probably not possible on such a system as this is the most difficult multicore setup to support (see above).

PhantomInterrogative Quote:

If you want a faster than 1990s tech 68k performance today, get a Buffie, a Vampire, or good ol' WinUAE on a fast PC. I have been using WinUAE since I sold my SAM460 lite. It actually feels faster than the SAM (I haven't done benchmarks).

It's not difficult to beat the Pentium killer in performance today. Ironically, the Pentium killer is often being emulated by the Intel i3, i5, i7 which are based on the OoO Pentium Pro architecture. My 68060 slightly outperforms the Pentium Pro in integer performance for the ByteMark benchmark at the same clock speed too. It's amazing what chip process technology can do for one processor and what politics can do for another. It doesn't take long for their performances to diverge.

Last edited by matthey on 15-Jan-2022 at 05:21 AM.
Last edited by matthey on 15-Jan-2022 at 05:04 AM.

@QBit

I wonder if the PC would have become the machine it was without the Amiga? I think it eventually would have as it didn't look like they noticed what the Amiga was doing. Kind of like how some people think Raiders of The Lost Ark wouldn't have ended up any different if Indiana Jones wasn't in the movie.

But running MSDOS on an i9 seems far apart to emulating an Uber Amiga. Assuming you don't mean an Amiga taxi service where an Uber Amiga drives people around in an Amiga car

If Jobs said the Mac would never have colours, then he said it on purpose, because he wanted to limit what it would be and produce a computer dumbed down as much as possible. Limited by design, not by technology. But, Photoshop was developed on a B&W Mac. And one of the Myst programmers used a B&W Mac hacked with a card to produce colour. So it doesn't look like colour was thought to be a big deal once.

I'm sure there could be a multi core Amiga if someone produces a multi CPU accelerator card. It likely would only run special games. Doom on planar would be a lot faster in multicore. And if we ignore Forbid then surely a slightly crippled AmigaOS could run multicore as well.

But translating that to am emulator is a different story. Multicore cannot not emulated as simulated multitiple threads in a single thread model loses value and isn't the same. It would need to be emulated in parallel on host CPU cores.

Last edited by Hypex on 16-Jan-2022 at 03:23 PM.

@PhantomInterrogative

Quote:

If you want a faster than 1990s tech 68k performance today, get a Buffie, a Vampire, or good ol' WinUAE on a fast PC. I have been using WinUAE since I sold my SAM460 lite. It actually feels faster than the SAM (I haven't done benchmarks).

Surely you would need to emulate OS4 in classic mode which would be a crippling experience?

I think a more accurate emulation would be with QEmu emulating a Sam.

But then it lacks a WinUAE GUI and may be harder to setup and experimental.

@Hypex

Quote:

Hypex wrote: @PhantomInterrogative Quote: If you want a faster than 1990s tech 68k performance today, get a Buffie, a Vampire, or good ol' WinUAE on a fast PC. I have been using WinUAE since I sold my SAM460 lite. It actually feels faster than the SAM (I haven't done benchmarks). Surely you would need to emulate OS4 in classic mode which would be a crippling experience?

Better emulate Amiga on WinUAE in Amiga mode.

@QBit

It's a nice dream. I have a similar dream, and I even discussed with Ben (Hyperion) the possibility of licensing access to the Amiga OS 3.1 source to further research my ideas and concepts. I assured him I was not looking to port it to another ISA, and that I would share any improvements that would be made. Alas, Ben wanted a lot more $ than I had at my disposal.

@matthey and I have also discussed at length the various options and possibilities for a new 68k ASIC, and there's a lot of promising options there, but of course that too requires quite a bit of investment.

Essentially, what you are proposing is, as you say, well within the sphere of "possible", but just because it is possible does not mean it's worth the time (money) and effort. But it would be an awesome passion project nonetheless.

By creating a custom 68k core (SMP/AMP/64-bit) in software, you would end up using WinUAE as a hardware DE. I get it.
As other's have pointed out, it would also require new software silicon for a new chipset that would work with the new 68k core. Whether or not the new custom chipset design would have backward compatibility, and to what degree, it would still require a large investment.

I personally do not care about backwards compatibility. I'm always more interested in forward motion. Outside proving some academic point, and as others have mentioned, once backward compatibility is out of scope there are many existing microprocessor architectures that would be more cost effective than back-porting decades of CPU design progress into the 68k architecture.

Many millions of dollars would be required to create your software only UBER Amiga, but the returns would be very limited. There was a time, before Commodore went bankrupt, to have a forward looking Amiga that would foster new development while also maintaining backward compatibility with a large % of older software. Back when 5% of global personal computer users were using an Amiga.

The way I see it, there are plenty of emulation and physical hardware options to run old Amiga 68k software. What I care about is creating a new pool of developers for a new system which can potentially offer the market an alternative to the Windows/macOS "lesser of two evils" stagnant ecosystem. If a new 68k core can play a role, that would be great, but it's not essential to the plan.

_________________
All the way, with 68k