@Hypex

Quote:

Hypex wrote: Oh not. Not reusing FPU. Well, at least it's not an SPE. From a technical point of view, PPC or POWER, does differ from AMD64 by having at least 32 registers for general, FPU and vector. So, it does hedge its bets, so to speak, on a maximal register count. 32x128 bits makes 4096 bits. 16x256 bits matches that. So, in full width alone, PPC was ahead until AVX256 matched it. AVX512 surpasses that. 16x512 bits is 8192 bits. A VSX with 64x128 bits would be able to match that with 8192 bits again. Unfortunately, reusing the FPU registers, just looks like an old x86 FPU hack. Looking desperate there. Now, any full width VMX or VSX can do that matches or beat x86 is some areas, is rather moot if it's unable to work on that desired width divided into smaller vectors using one operation. Of course, RISC does need to split operations into greater codes. But doing what looks like loop unrolling one one CPU when another can do it all in one, won't look as efficient.

FYI, X86-64v4's AVX-512's EVEX encoding has 32 vector registers i.e. zmm0 to zmm31 for AVX-512, ymm0 to ymm31 for AVX-256 and xmm0 to xmm31 for AVX-128.

AVX supports both integer and floating-point formats.

32 zmm registers x 512 bit = 16,384 bits.

Linux world has X86-64 version levels to simplify Intel's X86-64 SIMD instruction set mess.

_________________
Ryzen 9 7900X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB
Amiga 1200 (Rev 1D1, KS 3.2, PiStorm32lite/RPi 4B 4GB/Emu68)
Amiga 500 (Rev 6A, KS 3.2, PiStorm/RPi 3a/Emu68)

@Gunnar

Quote:

Gunnar wrote: @Hypex Quote: Is there an AHI driver yet? Yes, of course. We provide AHI drivers.

Of course you do.

http://www.apollo-core.com/knowledge.php?b=1&note=29981

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@kolla

Quote:

Is there an AHI driver yet?

Gunnar
Quote:

Yes, of course. We provide AHI drivers.

Correct ship AHI driver already pre-installed in ApolloOS
and also available for download since many years.

These AHI driver allows you to use high quality 16bit Audio.




Regarding AHI.
AHI by design works somewhat against the concept of Amiga designers.
The Amiga computer design is based on the Amiga DMA hardware doing the work.

What does DMA mean?
DMA means "direct memory access"
This means the Amiga chipset can by itself read or write from memory and the CPU not needs to push memory around to e.g. display gfx or make sprites move, or make a sound play.

The Amiga Computer design is based on this all be done by the Amiga chipset with DMA.


Where is the violation of AHI?
The violation to the Amiga spirit of the AHI abstraction layer is
that it requires the CPU to push all the memory around for Audio is played.


Is this violation good or bad?
If you speak to Amiga designers and engineers like Dave Haynie
or if you speak to Amiga Modplayer developers then
that you will hear is that using DMA on the Amiga is one of its key strength.
And using the CPU for this is against the good concept of the Amiga.

@Gunnar

I don't know that AHI precludes DMA does it? The main issue is with mixing virtual channels into physical ones. In principle, this can be done by the hardware as AHI's device (and maybe even library) interfaces don't mandate what the implementation does, only how to use it.

The reality of course is that many third party sound cards that have AHI drivers end up in a CPU mixing, CPU submission to HW situation because they are just DAC/ADC boards. Even those with DSP that could do mixing don't necessarily have the mechanisms in place to perform DMA from elsewhere in the system to get the benefit of that.

_________________
Doing stupid things for fun...

@Gunnar

Symphonie Pro has 128 voices.
4 hardware channels it too few, if you want to make really good tracks.

https://www.youtube.com/watch?v=w5_jDiBE_tU

Don’t get me wrong I love many pro-tracker modules.
But Symphonie Pro modules just sound better.

They are also 14bit, I love 16bit version of it,
and I just discovered it might be possible the source code was released.

Last edited by NutsAboutAmiga on 11-Mar-2024 at 04:58 PM.

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS

@Hypex

Quote:

Hypex wrote: @cdimauro Quote: Not yet. If you use ffmpeg to encode a video with the latest HEVC/H.265 codec you can see from its output console that it's still using the MMX extension. Just to give a notable example. That's interesting being the latest. I would have expected it to use the latest extensions. It then doesn't need too and perhaps MMX could be better suited though I don't know that.

Or maybe because the processor can run some MMX instructions in parallel with other ones.
Quote:

Quote: x87 is also used in several softwares. You can also use in WinUAE, for example. x87 is almost as entrenched as x86 itself so it would be hard to simply displace it. Sure, standards and CPU designs change, but x86[-x64] usually implies x87 support as well. Well a modern variant of x87 now days.

It stays there until a future SIMD/vector extension supports 128-bit FP precision. Otherwise x87 with its 80 FP precision has still its value on some areas of the computation (and emulation).
Quote:

Quote: Indeed. They only doubled the number of "vector" registers with VSX, by reusing the floating point ones and extending them to 128 bits. Oh not. Not reusing FPU. Well, at least it's not an SPE. From a technical point of view, PPC or POWER, does differ from AMD64 by having at least 32 registers for general, FPU and vector. So, it does hedge its bets, so to speak, on a maximal register count. 32x128 bits makes 4096 bits. 16x256 bits matches that. So, in full width alone, PPC was ahead until AVX256 matched it. AVX512 surpasses that. 16x512 bits is 8192 bits. A VSX with 64x128 bits would be able to match that with 8192 bits again. Unfortunately, reusing the FPU registers, just looks like an old x86 FPU hack. Looking desperate there. Now, any full width VMX or VSX can do that matches or beat x86 is some areas, is rather moot if it's unable to work on that desired width divided into smaller vectors using one operation. Of course, RISC does need to split operations into greater codes. But doing what looks like loop unrolling one one CPU when another can do it all in one, won't look as efficient.

Just counting the overall bits it not how it works.

What's important is how many bits (!) you can process in parallel with a single SIMD/Vector instruction.

Even with its double amount of register's, VSX is still a 128-bit SIMD unit. So, a single instruction can process at most 128 bits at the time.

AVX (no even AVX-2) can process 256 bits at the time. AVX-512 can do 512 bits at the time.

It means that to compete with them then a PowerPC with VSX extension should execute more instructions. Even much more. Which means that both the frontend and backend of the processors should support decoding and execution much more instructions compared to an x86 core.

Even if in principle a PowerPC could be smaller than a x86 core, it's not able to keep-up and compete. It can have some chance only if the core is expanded by decoding and executing many instructions, but it can easily become a monster and very inefficient (from a power consumption).

VSX is a clear example of a design failure: engineers haven't understood how to better use the transistors for addressing the big computation challenges.
Quote:

Quote: Oh no. More extensions. A main issue is compatibility. It looks like they ensured that.

And it's also a nice extension. At least, it brings innovation in the panorama of vector extensions.
Quote:

That's good for POWER but I won't expect it to be in a new AmigaOne any time soon.

Why you're so pessimistic? It only needs two more weeks!
Quote:

Quote: Intel is still at 512 bits (AVX-512). The prefix encoding allows to specify another vector length, so 1024 is definitely possible, but if Intel's engineers aren't stupid they should used for a vector extension instead of another packed/SIMD one. The actual packed/SIMD can be left as it is. More complexity. Not that it matters any more. As over the next few years they will manage to advance even more features. So 16384 here we may come.

No way. It's too much. Even 512-bits to be processed in parallel is A LOT.

The main problem when expanding the SIMD/vector register size is that sending a lot of bits in the internal bus of the CPU leads to clock skew issues: https://en.wikipedia.org/wiki/Clock_skew

This limits the highest frequency that a system might reach. So, the more bits you process / sends around at the time, the more synchronization problems the chip faces, limiting the frequency of execution.

On top of that, processing a massive amounts of data requires a lot of power which the chip consumes. Also temperatures go up.

So, there are many problems and it's insane thinking to scale a processor's "power" (performance) by "simply" doubling the SIMD/vector register sizes each time.

@Hammer

Quote:

Hammer wrote: @Hypex Quote: Hypex wrote: Oh not. Not reusing FPU. Well, at least it's not an SPE. From a technical point of view, PPC or POWER, does differ from AMD64 by having at least 32 registers for general, FPU and vector. So, it does hedge its bets, so to speak, on a maximal register count. 32x128 bits makes 4096 bits. 16x256 bits matches that. So, in full width alone, PPC was ahead until AVX256 matched it. AVX512 surpasses that. 16x512 bits is 8192 bits. A VSX with 64x128 bits would be able to match that with 8192 bits again. Unfortunately, reusing the FPU registers, just looks like an old x86 FPU hack. Looking desperate there. Now, any full width VMX or VSX can do that matches or beat x86 is some areas, is rather moot if it's unable to work on that desired width divided into smaller vectors using one operation. Of course, RISC does need to split operations into greater codes. But doing what looks like loop unrolling one one CPU when another can do it all in one, won't look as efficient. FYI, X86-64v4's AVX-512's EVEX encoding has 32 vector registers i.e. zmm0 to zmm31 for AVX-512, ymm0 to ymm31 for AVX-256 and xmm0 to xmm31 for AVX-128.

As I've already repeated you several times: there's no AVX-128. Neither AVX-256.

There's only AVX, which is always 256 bit. But you can decide to use the LOWER 128 bits of the 256 registers.
Quote:

AVX supports both integer and floating-point formats.

With 256 bit registers. Always. Whatever is the implementation. Registers are always 256 bits. And a single instruction can compute 256 bits.

Even with the first AVX.

@NutsAboutAmiga

Quote:

4 hardware channels it too few, if you want to make really good tracks.

On the other hand there are many very good Amiga 4 channel mods.
But of course more channels make live a lot easier.

Sound mixing with CPU burns a lot CPU time.
Symphonie can easily eat a 68030 CPU.

Compared to this playing Hardware channel music is "free".

@cdimauro

Quote:

As I've already repeated you several times: there's no AVX-128. Neither AVX-256.

Read https://en.wikipedia.org/wiki/AVX-512

AVX-512's EVEX SIMD modes
AVX-128 (EVEX) with xmm0–xmm31 registers.
AVX-256 (EVEX) with ymm0–ymm31 registers.
AVX-512 (EVEX) with zmm0–zmm31 registers.

Intel's 355989-intel-avx10-spec.pdf's feature table 1-3


Under Intel's AVX10.1 and AVX10.2 road map, the 512-bit register support is optional.

AVX's VEX SIMD modes
AVX-128 (VEX) with xmm0–xmm15 registers.
AVX-256 (VEX) with ymm0–ymm15 registers.

My AVX-128 with AMD's Jaguar refers to the AVX 128-bit hardware implementation. AVX-256 ISA is a "double pump" (two clock cycles ) into 128-bit AVX SIMD hardware as compatibility mode. This path will delay instruction retirement!

Intel's Gracemont E-Cores has two 128-bit AVX2 SIMD FP units with 256-bit AVX2 ISA compatibility.

Instruction set debates are meaningless without stating the microarchitecture implementation.

Your argument position is less transparent when you hide the less optimal code path.

Furthermore, Intel's AVX10.1 and AVX10.2 made AVX-512 optional.

Last edited by Hammer on 13-Mar-2024 at 04:53 AM.
Last edited by Hammer on 13-Mar-2024 at 04:53 AM.
Last edited by Hammer on 13-Mar-2024 at 04:10 AM.
Last edited by Hammer on 13-Mar-2024 at 04:08 AM.
Last edited by Hammer on 13-Mar-2024 at 04:01 AM.

_________________
Ryzen 9 7900X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB
Amiga 1200 (Rev 1D1, KS 3.2, PiStorm32lite/RPi 4B 4GB/Emu68)
Amiga 500 (Rev 6A, KS 3.2, PiStorm/RPi 3a/Emu68)

@cdimauro

Quote:

With 256 bit registers. Always. Whatever is the implementation. Registers are always 256 bits. And a single instruction can compute 256 bits.

It depends on the microarchitecture implementation.

AMD Jaguar or Intel Gracemont will break 256-bit AVX instructions into two 128-bit instructions in a "double pump" (two-cycle) dispatch. This purpose is to conserve decode issue slots, and maintain full software compatibility with fat CPU cores. The cost reduction penalty is delayed instruction retirement.

Low-cost CPU cores have cost reduction measures.

_________________
Ryzen 9 7900X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB
Amiga 1200 (Rev 1D1, KS 3.2, PiStorm32lite/RPi 4B 4GB/Emu68)
Amiga 500 (Rev 6A, KS 3.2, PiStorm/RPi 3a/Emu68)

@cdimauro

Quote:

cdimauro wrote: No way. It's too much. Even 512-bits to be processed in parallel is A LOT. The main problem when expanding the SIMD/vector register size is that sending a lot of bits in the internal bus of the CPU leads to clock skew issues: https://en.wikipedia.org/wiki/Clock_skew This limits the highest frequency that a system might reach. So, the more bits you process / sends around at the time, the more synchronization problems the chip faces, limiting the frequency of execution. On top of that, processing a massive amounts of data requires a lot of power which the chip consumes. Also temperatures go up. So, there are many problems and it's insane thinking to scale a processor's "power" (performance) by "simply" doubling the SIMD/vector register sizes each time.

It depends on the micro-architecture's implementation of the target instruction set.

For AVX-512, AMD's Zen 4 has no large clock speed degradation when compared to Intel's SkyLake-X / Cascade Lake.

On CPU-Z's normal vs AVX-512 benchmarks, it's about 100 Mhz reductions on the Ryzen 5 7600X.

Last edited by Hammer on 13-Mar-2024 at 05:46 AM.
Last edited by Hammer on 13-Mar-2024 at 05:28 AM.
Last edited by Hammer on 13-Mar-2024 at 05:27 AM.

_________________
Ryzen 9 7900X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB
Amiga 1200 (Rev 1D1, KS 3.2, PiStorm32lite/RPi 4B 4GB/Emu68)
Amiga 500 (Rev 6A, KS 3.2, PiStorm/RPi 3a/Emu68)

@Hammer

Quote:

Hammer wrote: @cdimauro Quote: As I've already repeated you several times: there's no AVX-128. Neither AVX-256. Read https://en.wikipedia.org/wiki/AVX-512 AVX-512's EVEX SIMD modes AVX-128 (EVEX) with xmm0–xmm31 registers. AVX-256 (EVEX) with ymm0–ymm31 registers. AVX-512 (EVEX) with zmm0–zmm31 registers.

I don't read Wikipedia: I read Intel's and AMD's architecture manuals. Hence, I've already acquired the knowledge singe AGES. The RIGHT knowledge. And I don't need to read something that anyone can write and write it wrong.
Quote:

Intel's 355989-intel-avx10-spec.pdf's feature table 1-3 Under Intel's AVX10.1 and AVX10.2 road map, the 512-bit register support is optional.

Indeed. What's not clear to you that the SIMD extension is called AVX10 and that it has sub-features / sub-sets defined / qualified by a dot following a number? Nevertheless, the extension is called AVX10: there's no AVX-128 neither AVX-256.

The / defines the supported maximum size of the specific extension definition.
Quote:

AVX's VEX SIMD modes AVX-128 (VEX) with xmm0–xmm15 registers. AVX-256 (VEX) with ymm0–ymm15 registers.

There's no "SIMD mode" like that on the AVX. That's a complete invention. In fact, AVX always works using 256 bit registers.

You can executed AVX instructions which either use the full register size or only the lowest 128 bits (but then the upper 128 bits will be cleared). So, you ALWAYS use 256 bits.

A simple example from Intel's architecture manual about an instruction which uses only the lowest 128 bits:
VEX.128.66.0F.WIG 58 /r VADDPD xmm1,xmm2, xmm3/m128
Add packed double-precision floating-point values from xmm3/mem to xmm2 and store result in xmm1.

VEX.128 encoded version: the first source operand is a XMM register. The second source operand is an XMM register or 128-bit memory location. The destination operand is an XMM register. The upper bits (MAXVL-1:128) of the corresponding ZMM register destination are zeroed.

I've highlighted the relevant part for YOUR benefit.
Quote:

My AVX-128 with AMD's Jaguar refers to the AVX 128-bit hardware implementation. AVX-256 ISA is a "double pump" (two clock cycles ) into 128-bit AVX SIMD hardware as compatibility mode. This path will delay instruction retirement!

YOUR (as you finally reported) is a completely invented definition which has no meaning in the real world, since the AVX ISA extension is ALWAYS 256 bit even when executing instructions working on the lowest 128 bit, as I've reported from Intel's manual.

But what's most important, implementations are totally irrelevant when talking about an ISA = Instruction Set Architecture.

So, who cares if AMD's Jaguar internally works using only 128 bit at the time.
Quote:

Intel's Gracemont E-Cores has two 128-bit AVX2 SIMD FP units with 256-bit AVX2 ISA compatibility.

See above: IRRELEVANTI.
Quote:

Instruction set debates are meaningless without stating the microarchitecture implementation.

That's a complete non-sense. Instruction set debates have NOTHING to do with their possibile implementations.

An ISA is a clearly defined thing. A microarchitecture is just one of the possible implementations. Only the latter is, obviously, dependent from the first, but the viceversa is always NOT the case (unless you can PROVE it, of course. Which I STRONGLY DOUBT).
Quote:

Your argument position is less transparent when you hide the less optimal code path.

I don't need to hide something: I "only" don't talk of apples and oranges when the discussions should be only about apples.

And that's because I KNOW of what I'm talking about. Which is clearly NOT your case...
Quote:

Furthermore, Intel's AVX10.1 and AVX10.2 made AVX-512 optional.

Yes, and what's not clear to you that those ISA definitions are called AVX10.1 and AVX10.2?
Quote:

Hammer wrote: @cdimauro Quote: With 256 bit registers. Always. Whatever is the implementation. Registers are always 256 bits. And a single instruction can compute 256 bits. It depends on the microarchitecture implementation.

No! The microarchitecture always works with 256 bits SIMD register sizes. WHATEVER is its internal implementation. See above what I've reported from the manual.
Quote:

AMD Jaguar or Intel Gracemont will break 256-bit AVX instructions into two 128-bit instructions in a "double pump" (two-cycle) dispatch. This purpose is to conserve decode issue slots, and maintain full software compatibility with fat CPU cores. The cost reduction penalty is delayed instruction retirement. Low-cost CPU cores have cost reduction measures.

See above: completely irrelevant, since the discussion is about architectures = ISAs = Instruction Set Architectures.
Quote:

Hammer wrote: @cdimauro Quote: cdimauro wrote: No way. It's too much. Even 512-bits to be processed in parallel is A LOT. The main problem when expanding the SIMD/vector register size is that sending a lot of bits in the internal bus of the CPU leads to clock skew issues: https://en.wikipedia.org/wiki/Clock_skew This limits the highest frequency that a system might reach. So, the more bits you process / sends around at the time, the more synchronization problems the chip faces, limiting the frequency of execution. On top of that, processing a massive amounts of data requires a lot of power which the chip consumes. Also temperatures go up. So, there are many problems and it's insane thinking to scale a processor's "power" (performance) by "simply" doubling the SIMD/vector register sizes each time. It depends on the micro-architecture's implementation of the target instruction set.

Correct. THIS is about microarchitectures.
Quote:

For AVX-512, AMD's Zen 4 has no large clock speed degradation when compared to Intel's SkyLake-X / Cascade Lake. On CPU-Z's normal vs AVX-512 benchmarks, it's about 100 Mhz reductions on the Ryzen 5 7600X.

Is AMD's implementation splitting the AVX-512 instructions in two micro-ops working on 256 bits at the time?

@Hammer

Quote:

Read https://en.wikipedia.org/wiki/AVX-512

Hammer did you know that this is an Amiga Forum?

Can you stop cross posting Intel stuff from Wikipedia to an Amigaforum?

@cdimauro

Quote:

I don't read Wikipedia: I read Intel's and AMD's architecture manuals. Hence, I've already acquired the knowledge singe AGES. The RIGHT knowledge. And I don't need to read something that anyone can write and write it wrong.

https://community.intel.com/t5/Intel-ISA-Extensions/unaligned-loads-avx-128-vs-256/m-p/949434

AVX-128 is a real terminology for direct SSE intrinsic to AVX-128 port.

https://www.intel.com/content/dam/develop/external/us/en/documents/11mc12-avoiding-2bavx-sse-2btransition-2bpenalties-2brh-2bfinal-809104.pdf
Subject : Introduction to AVX-SSE transition penalties

Intel has "128-bit Intel AVX" instruction terminology usage.

Unlike you, I'm transparent with the microarchitecture's implementation.

Front-end instruction sets are meanless when performance is attached to the debate.

Furthermore, certain AVX-128 small-datatypes don't scale with AVX-256-bit registers and they are not available. Read Page 3 from https://hpc.llnl.gov/sites/default/files/intelAVXintro.pdf

Newer AVX extensions have BF16 or FP16, VNNI (byte, word) smaller datatypes for 256-bit and 512 registers.

There are gotchas with AVX.

Quote:

Is AMD's implementation splitting the AVX-512 instructions in two micro-ops working on 256 bits at the time?

That's correct.

For Zen 4, AVX-512 is used as an instruction issue slot conservation, 32-register programming model, and access to AVX-512's Ice Lake extensions. The four 256-bit SIMD units are not symmetric (two FMA3 complex, two FADD simple), hence they have gotchas.

https://www.phoronix.com/review/intel-sapphirerapids-avx512/8
There's a larger AVX-512 uplift with Intel Sapphire Rapids when compared to AMD's Genoa's.

AMD (96 cores with EPYC 9654) still beats Intel (60 cores with Xeon Platinum 8490H) due to a larger CPU core count due to perf/watt advantage. EPYC's Zen 4C has reached 128 cores.

Zen 5 has improved on Zen 4's AVX-512 cost-reduction design i.e. full-performance AVX-512.
https://www.hwcooling.net/en/amd-confirms-zen-5-details-6-alus-full-performance-avx-512en/

GCC confirms that Zen 5 contains 512-bit SIMD units for the first time in AMD processor history.

My main selection criteria for AM5 is a proper CPU microarchitecture upgrade roadmap.

Last edited by Hammer on 13-Mar-2024 at 01:57 PM.

_________________
Ryzen 9 7900X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB
Amiga 1200 (Rev 1D1, KS 3.2, PiStorm32lite/RPi 4B 4GB/Emu68)
Amiga 500 (Rev 6A, KS 3.2, PiStorm/RPi 3a/Emu68)

@Gunnar

Quote:

Gunnar wrote: @Hammer Quote: Read https://en.wikipedia.org/wiki/AVX-512 Hammer did you know that this is an Amiga Forum? Can you stop cross posting Intel stuff from Wikipedia to an Amigaforum?

Do you support AVX-512 has 16 registers?

_________________
Ryzen 9 7900X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB
Amiga 1200 (Rev 1D1, KS 3.2, PiStorm32lite/RPi 4B 4GB/Emu68)
Amiga 500 (Rev 6A, KS 3.2, PiStorm/RPi 3a/Emu68)

@Hammer

THIS FORUM IS AN AMIGA FORUM.


GUNNAR:
Quote:

Hammer did you know that this is an Amiga Forum? Can you stop cross posting Intel stuff from Wikipedia to an Amigaforum?

HAMMER:
Quote:

Do you support AVX-512 has 16 registers?

What is wrong with you?
Are you on drugs?

@ppcamiga1

FACTS:

1. 68k is DEAD as a mainstream platform.

2. PPC is DEAD as a mainstream platform.

3. Any attempt to make a PPC version of an AmigaOS came with a 68k emulator. Why? Because almost ALL software available for Amiga is made for 68k.

4. The main reason for using a 68k machine nowadays is NOSTALGIA, it's to remember when you discovered such a wonderful machine, the Amiga. F.ex., can you access your bank webpage with iBrowse, or, fwiw, many other modern web pages? Even if you could, the machine CRAWLS because lack of power. Even with a PiStorm installed…

5. A QUARTER OF CENTURY AGO, PPC was still an option, and that's why I bought a 1.000€ PPC board in 2001, an AmigaOne G4, and became betatester and translator for a PPC version of AmigaOS, because I thought that was the way, the same way Apple took. Now IT IS NOT: if you want it for modern computing, grab a modern computer.

5.1. A fact inside previous fact: AmigaOS PPC developers, althought very motivated and competent, did not have the resources of, i.e., Apple, so development was sloooooow. So slow than even Apple switched processor in favour of Intel one when AmigaOS 4 was still in development (circa 2005). And PPC, without Apple, became a de facto dead platform.

5.2. And even Apple used, for the transition, first a 68k emulator over PPC, then a PPC emulator over Intel (Rosetta) and now an Intel emulator over Mx processors (Rosetta 2), but the goal was NOT to keep old software running forever, but to allow a smooth transition to versions of progs compiled for the new processor. In Amiga maybe the intention was the same, with a HUGE difference: by 2005 there were almost NO DEVELOPERS of commercial software working for Amiga, so there were not going to be "new versions of the old softwarecompiled for the new CPU", so the emulator became almost THE ONLY WAY to have software for that PPC machine.

All in all: it's not that the PPC is bad, it is not. It's simply obsolete, not an option: why would anyone buy TODAY a VERY expensive PPC machine to run emulated 68k programs? 🤔

If I had the option to choose NOW, repeat, NOW, I'd prefer an inexpensive and popular ARM machine (i.e. RPi) with AmigaOS compiled for it and an embedded 68k emulator for old Amiga programs. Why? IMHO, it would be far easier to get people involved paying 40€ instead of 1.000€, for a machine that can boot on several other OS with modern capabilities.

In the meantime of not having such option, I'll be using my Classic 68k machines for 68k software, making experiments on it like PiStorm and the like, buying old SCSI stuff for my SCSI device, etc.

And those were "just my two cents"…

Saluditos,

Ferrán.

_________________
Amiga user since 1988
AOS4 Betatester
Member of ATO Spain
A1 Cfg
OS4 SCR
A1200

@Hammer

Quote:

Hammer wrote: @Gunnar Quote: Gunnar wrote: @Hammer [quote]Read https://en.wikipedia.org/wiki/AVX-512 Hammer did you know that this is an Amiga Forum? Can you stop cross posting Intel stuff from Wikipedia to an Amigaforum?

Do you support AVX-512 has 16 registers?
[/quote]

Who cares? Whether it has 16 or 2**16 is completely irrelevant.

_________________
Doing stupid things for fun...

@Karlos

Quote:

Karlos wrote: Who cares? Whether it has 16 or 2**16 is completely irrelevant.

It's relevant when the error is 2X.

_________________
Ryzen 9 7900X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB
Amiga 1200 (Rev 1D1, KS 3.2, PiStorm32lite/RPi 4B 4GB/Emu68)
Amiga 500 (Rev 6A, KS 3.2, PiStorm/RPi 3a/Emu68)

@Gunnar

Quote:

Gunnar wrote: @Hammer THIS FORUM IS AN AMIGA FORUM. GUNNAR: Quote: Hammer did you know that this is an Amiga Forum? Can you stop cross posting Intel stuff from Wikipedia to an Amigaforum? HAMMER: Quote: Do you support AVX-512 has 16 registers? What is wrong with you? Are you on drugs?

Reminder, WinUAE, Cloanto's Amiga Forever (with official Amiga Corporation's licensed AmigaOS 3.X, standalone bootable into Linux KX Light/UAE) and Amithlon run on X86 PCs.

My licensed Amiga Forever 2016 is bundled with licensed AmigaOS 4.1 FE.

My WinUAE's AmigaOS 4.1 FE installation is operational with 3D acceleration i.e. WinUAE's 3D API bridge or 3DFX Voodoo 3. I have a Ryzen 5 7600X PC dedicated to WinUAE and QEmu 8.2.

Your ApolloOS (AROS-based) is not even Amiga Corporation licensed.

I find it strange when Amiga Corporation's and Hyperion Entertainment's officially licensed product that runs on X86 PCs is ejected from this Amiga forum. LOL

This is not your censored Apollo Forum.

Look in the mirror.
---

When the price and certain PowerPC model are right for AmigaOS 4.1 FE PowerPC hardware, there's a high probability I will purchase it. PowerPC e6500 is on my consideration list.

I already reserved an AMD GCN GPU card (specifically, Sapphire's Radeon HD "7970 3G GDDR5 OC with Boost, 1197-03-40G) that is compatible with A-EON's Enhancer System 54. https://hdrlab.org.nz/projects/amiga-os-4-projects/radeonhd-driver/radeonhd-driver-hardware-compatibility

Last edited by Hammer on 14-Mar-2024 at 01:30 AM.
Last edited by Hammer on 14-Mar-2024 at 01:24 AM.

_________________
Ryzen 9 7900X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB
Amiga 1200 (Rev 1D1, KS 3.2, PiStorm32lite/RPi 4B 4GB/Emu68)
Amiga 500 (Rev 6A, KS 3.2, PiStorm/RPi 3a/Emu68)