@megol

Wow It must be great to understand this stuff!

To summarise then for us that don't analyse how FPUs and SPEs work at the transistor level :

The Apollo core is a fast and dirty implementation of 68k IMHO that cannot hope to compete with even the PPC line of SOCs in the near future for raw performance or usefulness to the Amiga going forwards. However, since the Vampire project is about having fun and supplying people with new accelerated Classic Amigas that they would otherwise be sourcing from eBay for £1000s then it doesn't really matter!

I can't see that Apollo will lead to a future for 68k that will eclipse PPC but why not rejoice and make hay while the sun shines?

_________________
"Art challenges technology. Technology inspires the art."
John Lasseter, Co-Founder of Pixar Animation Studios

@BigD

I'm guessing that the Vampire project is several times more succesful in terms of sales(that is without supporting some of the most popular Amigas) than any of the NG Amiga project... Hence renewed interest from the various companies on 68K products.

At this stage, PPC Amigas are a dead end. OS4 is, for all intents and purposes, dead man walking while MOS is migrating to x86.

_________________

@WolfToTheMoon

AMD64 propably

not X86 (32bit)

@BigD

PPC is dead too (at least on desktop market). Smartphones/Tablets are mostly ARM. If you need power there is Intel/AMD. The last niche are IBM servers...

Vampire/Apollo is a niche product but one with a real need in amiga terms

@WolfToTheMoon

As stated many times before, only users willing to buy new software/hardware are necessary for healthy (or at least semi-undead) market, others are mostly "ballast". Software developers would have been even more precious, but these are rare commodity in the world of Amiga.

If (I assume) most Vampire users buy this hardware to have powerful Amiga feeling and then only play old games, their market value is fairly limited.

@pavlor

You don't need Vampire to play old Amiga games.

Maybe the sales success of the Vampire will result in new games and apps being released for 68K, who knows.

The issues is that tge 68K market is getting healthier, while the PPC market is vanishing. Who would have thought of that 5-10 years ago

_________________

@WolfToTheMoon

If you say it.

Word of God.

Amen

Last edited by ribdevil on 04-Sep-2018 at 06:57 PM.
Last edited by ribdevil on 04-Sep-2018 at 06:57 PM.
Last edited by ribdevil on 04-Sep-2018 at 06:57 PM.

Quote:

megol wrote: No it isn't a significant cost and if there were they would still be there as the old encoding is still supported. The EVEX format supports more registers and both it and the VEX format is designed to open up more instruction space without needing any type of hacks (like some SSE instructions used). The 68k wouldn't need it of course however it wouldn't be a huge problem if it did. While 6 bytes may sound much the Itanium used 5 bytes (+ some extra) for every instruction without that being a bottleneck, for 68k 6 bytes instructions would be an exception rather than a rule.

Itanium was aimed at the high performance market also. The long instructions and many prefixes are not difficult for high performance hardware but they are for mid performance and energy efficient hardware. Take the early Intel Atoms for example.

Quote:

The instruction fetch rate is approximately 8 bytes per clock cycle on average when running a single thread. The fetch rate can get as high as 10.5 bytes per clock cycle in rare cases, such as when all instructions are 8 bytes long and aligned by 8, but in most situations the fetch rate is slightly less than 8 bytes per clock when running a single thread. The fetch rate is lower when running two threads in the same core. The instruction fetch rate is likely to be a bottleneck when the average instruction length is more than 4 bytes. The instruction fetcher can catch up and fill the instruction queue in case execution is stalled for some other reason.

https://www.agner.org/optimize/microarchitecture.pdf

Atom went back to a more energy efficient early in-order architecture which was unsuccessful (they abandoned this market and adopted less energy efficient targets). Long SIMD instructions were one of the reasons why it failed. They were counting on multi-threading to improve efficiency but long instructions reduced the sharing and expected efficiency gains. Multi-threading was probably a mistake but instruction fetch is expensive. The 68k has better code density and 16 bit aligned instructions which are an advantage over the x86. The 68060 is 42% more energy efficient and is using 21% fewer transistors compared to the most comparable in-order Pentium that the early Atom designs went back to for energy efficiency. The 68060 has good performance with just a 4 byte/cycle instruction fetch so I expect the 68060 could be successful where the Atom was not but moving to 6 byte SIMD instructions might change this. It may be better to limit the number of SIMD registers to 16 or stay with mostly 2 op instructions if SIMD instructions could be kept to 4 bytes. A CISC SIMD unit doesn't need as many registers as a RISC SIMD unit. Increased SIMD parallelism with wider registers uses less encoding space.

Quote:

Using only two bits would be a waste which is why I have sketched many different types of prefixes to reduce waste. But none of those use only two bits, the smallest used 6 bits IIRC out of the 11 available in the Coldfire MVZ/MVS space. So it would be possible to add 64 bit operations, 16 registers (each of Ax, Dx), sign/zero extension and other features to the standard instruction set. This would partially compensate the larger instructions however what features to include would need a simulator plus compiler support to decide.

With a 16 bit prefix, multiple functionality would need to be provided per prefix. The improved functionality would be convenient but I worry that code density would deteriorate. Adding instructions to free/available encoding space improves code density in comparison. My instincts prefer recovering some encoding space with a 64 bit mode where new instructions would be added without affecting 32 bit compatibility. I don't think adding more registers is worth the cost with a CISC CPU. Specifically, I haven't seen any statistics which show elevated instruction counts or memory traffic from the 68k only having 16 registers (statistics I have seen show it to be close to architectures with 32 registers in these categories). RISC needs more registers to reduce the increased instruction count and memory accesses which we do not. RISC needs larger register files, a larger instruction fetch, larger instruction caches and more memory which are major handicaps for performance and energy efficiency on mid-performance CPUs where I believe the 68k could shine. I would prefer to make more efficient use of the advantages we have.

I would like to see statistics, especially code density comparisons, if you added prefixes to a 68k compiler backend. It is no easy task as I would like to do the same for some of my ideas.

Quote:

I've looked at changing instructions with extension words but that is a huge pain to do effectively as the location of extensions words require decoding the first instruction word. So partial decode + extraction of extension word + detection of special extension word and changing of the decoded instruction. There would be other problems including detecting that a memory operation is actually using a new extension word.

A prefix is better than a postfix but a prefix delays finding the instruction size too (unless the instruction size is added to the prefix). Some of the Bonnell Atom CPUs have a 4 KiB instruction boundary mark cache so the pre-decoder can mark where the instruction begins and ends (a cache miss results in a 3 cycle penalty) but this offsets the code density advantage of allowing a smaller L1 ICache. The 68k is easier to decode than the x86 and adding prefixes would reduce this minor advantage.

Quote:

I meant the Apollo core/project. Still they are the only ones AFAIK that are actually doing a 68k update.

It wouldn't be that difficult to obtain an existing core or start from new. There are other options than the Apollo core but you do have to pay to play for professional quality cores and services unless you learn it all yourself. Team work is practically required.

@matthey

Quote:

The 68060 has good performance with just a 4 byte/cycle instruction fetch so I expect the 68060 could be successful where the Atom was not but moving to 6 byte SIMD instructions might change this. It may be better to limit the number of SIMD registers to 16 or stay with mostly 2 op instructions if SIMD instructions could be kept to 4 bytes.

I'm sold though I don't quite follow Where do I sign to open a new 68060 fabrication plant? Is that what we're doing? Why are we doing it again? Why are we trying to create a chip to compete with the Intel Atom? Is that chip still manufactured?

Seriously, I know we're talking about 68k development but are you seriously suggesting restarting the design and manufacture of these chips for the mass market? Are you insane? Coldfire had it's place but beyond the Apollo core there is NO chance of 68k being relevant to anyone other than Amiga/Atari people for small scale runs of these FPGA based chips. Surely you just talking hypothetical register / byte per cycle bullsh$t?

Last edited by BigD on 04-Sep-2018 at 10:18 PM.

_________________
"Art challenges technology. Technology inspires the art."
John Lasseter, Co-Founder of Pixar Animation Studios

Quote:

BigD wrote: I'm sold though I don't quite follow Where do I sign to open a new 68060 fabrication plant? Is that what we're doing? Why are we doing it again? Why are we trying to create a chip to compete with the Intel Atom? Is that chip still manufactured?

There would be no "new" 68060 fabrication plant but maybe an "old" fabrication plant. New fabs and die sizes are expensive but older fabs and processes are underutilized and become relatively cheap. We are still talking about several generations newer processes than the 68060 which would result in faster clock speeds. The 68060 design and process is quite old and would likely need major adaptions for today but it may be possible. There are people interested in the 68060 design and would likely trade work to convert the logic to a modern synthesizable form for a license to use it (I have talked to a professional). It could take some time and it may be better to just start over. The price may be prohibitive or the design may not be for sale. The advantages of acquiring the 68060 design are that it is fully qualified and that there are no know bugs. The CEO I was talking to about mass producing a CPU wanted a mature and professional design which the 68060 is.

All of the in-order Atom CPUs are out of production. The new Atom CPUs are higher performance OoO using micro-ops and the full x86_64 ISA but with energy saving features. Intel gave up on challenging ARM for mid performance CPUs. Intel has had trouble with energy efficiency and ARM has had trouble with performance. ARM adopted AArch64 to raise performance but lost code density and went to a more robust (fatter) RISC ISA much like PPC. Mid-performance CPUs are important as they have been selling in large quantities for portable electronic devices and SBCs like the Raspberry Pi. Spectre type attacks have made these CPUs more appealing as well. IMO, the Amiga needs very affordable mass produced hardware to expand their user base where a mid performance CPU would be used.

Quote:

Seriously, I know we're talking about 68k development but are you seriously suggesting restarting the design and manufacture of these chips for the mass market? Are you insane? Coldfire had it's place but beyond the Apollo core there is NO chance of 68k being relevant to anyone other than Amiga/Atari people for small scale runs of these FPGA based chips. Surely you just talking hypothetical register / byte per cycle bullsh$t?

ColdFire was targetted at low end embedded and lost most of the performance compared to the 68k. Only the ColdFire v5 was beginning to approach 68060 single core performance/clock and was never sold to the public. Motorola/Freescale didn't want to threaten their PPC embedded market with more powerful 68k designs which customers preferred. Many of those customers ended up moving to ARM and PPC died.

The 68060 is a strong and energy efficient CPU for the process and number of gates used yet there is much room for improvements. CISC has major performance and energy efficiency advantages compared to RISC that seem to be ignored today. I do believe the 68k could be viable today. 68k CPU designs may not be the fastest or the most energy efficient but they have consistently been competitive and outperformed expectations. The Apollo core is no exception with very good single core performance per clock, especially for an FPGA core.

@OlafS25

Quote:

The last niche are IBM servers...

I suspect networking gear even more so (all Juniper systems I have access to are powerpc), and aerospace.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@matthey

I know in the past you have had issues with how the Apollo core is being developed. However you have to understand this team is working with various constraints (time, resources, FPGA LE's, etc....) that aren't the same as Intel or AMD with their billion dollar budgets.

Having said that I think they are doing a great job on the 68080. Did you know that out of order execution support is coming? Current estimate is around 10% overall improvement on average. FPU is the first to use this.

The challenge is that they are developing both a CPU core and the full chipset replacement. Both very large projects on their own.

Hopefully V4/Core 3 comes out in the next couple of months. Will be quite interesting to see how it performs with this next generation.

@gregthecanuck

Quote:

Did you know that out of order execution support is coming?

And multithreading, how is that going?

Quote:

Current estimate is around 10% overall improvement on average. FPU is the first to use this.

The problem with the FPU (in its current form on V2) is not speed, it is lack of accuracy, which results in incompatibility with (among other things) the OS math libraries.

Quote:

The challenge is that they are developing both a CPU core and the full chipset replacement. Both very large projects on their own.

I never grasped why they need to work on the chipset replacement on their own. If the goal is to release as open source, it could have been that one thing one could gather various developers around and cooperate on.

Quote:

Hopefully V4/Core 3 comes out in the next couple of months. Will be quite interesting to see how it performs with this next generation.

Hm, what next generation?

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@kola

Multithreading: Troll attempt detected. Disinfected.

FPU: I expect to improve with core 3. Part of issue is simply lack of space in V2 FPGA. But you already know that. Trolling attempt detected. Disinfected.

Core/chipset: Goal is to advance 68K Amiga forward both in CPU and chipset capability... as if both the big M and C= hadn't screwed up. But you already know that. Troll attempt detected. Disinfected.

Next generation: V4 + Core 3 as noted.

Last edited by gregthecanuck on 05-Sep-2018 at 09:34 AM.

@gregthecanuck

Quote:

Multithreading: Troll attempt detected. Disinfected.

Not sure what to read from this answer... was multithreading support abandoned?
Or is it already in use?

Quote:

FPU: I expect to improve with core 3. Part of issue is simply lack of space in V2 FPGA. But you already know that. Trolling attempt detected. Disinfected.

Core3 fixes the FPU situation on v2 simply by not providing any FPU, as far as I know.

Quote:

Core/chipset: Goal is to advance 68K Amiga forward both in CPU and chipset capability... as if both the big M and C= hadn't screwed up. But you already know that. Troll attempt detected. Disinfected.

Goal was to make a new common ground for amiga developers, a new base standard for 68k Amiga - is that no longer a goal?

Quote:

Next generation: V4 + Core 3 as noted.

"NG" is already taken, this was confusing.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@megol

I don't have anything against enhancing the 68K, IF it's done right.
Right now it's limited to one man's vision.
And since only projects he is involved in use the core, outside input only seems to face scorn or ridicule.

Hopefully the core will pick up some licensees and a community will develop around it that is focused on evolutionary not revolutionary refirect.

On the SPE, it is a reduced function component and is NOT as powrrful as a standard fpu.
Also, to those that have mention the evolution of VMX, this is AltiVec (or at least the early versions were interchangeable), and the new advances look very useful.

Finally, I have nothing against the idea of BOTH 68K and PPC being further developed.

As has been pointed out, NG is currently only half way there ad long as it's only goal is providing 3.1 equivalent functionality.
And 3.1 (and later) 68K IS code could certainly stand to be cleaned up and modernized.

Frankly, I'd have no problem with a 68K IS 4.0, and more similarity between 68K and PPC operating systems.

Even although I am primarily a MorphOS user, I can tell you OS4 is an advance over OS3.x, and it would be nice to all be on the same page.

Quote:

gregthecanuck wrote: I know in the past you have had issues with how the Apollo core is being developed. However you have to understand this team is working with various constraints (time, resources, FPGA LE's, etc....) that aren't the same as Intel or AMD with their billion dollar budgets.

I understand the constraints. I was an Apollo team member when Gunnar was trying to squeeze a 68020 compatible core into the first Vampire. There weren't many choices then. Later, I suggested keeping the SIMD unit experimental while working on the FPU for compatibility. Many team members argued with me that the 68k has enough registers and fewer would reduce resources. On the other hand, I believe I was the first to suggest adding gfx output and some AGA compatibility to the accelerators for the value it would add despite using resources and time. I wasn't too concerned about making mistakes in an FPGA as they can be fixed but ISA mistakes are more difficult to change.

Quote:

Having said that I think they are doing a great job on the 68080. Did you know that out of order execution support is coming? Current estimate is around 10% overall improvement on average. FPU is the first to use this.

I have heard about the OoO but I'm not sure that it is a first for the Apollo core. Integer division may execute OoO as other instructions can execute at the same time. Some other CPUs execute division in non-integer units but not the 68060 division which is pOEP only. The 68060 can execute integer instructions at the same time as FPU instructions which are a varying number of cycles. Parallel execution in different units gives some of the benefit of OoO in a single unit. I hope this doesn't mean Gunnar has merged the FPU with the integer/SIMD unit. Sadly, the Apollo core is looking more like the Tabor CPU design all the time. I certainly don't know what Gunnar is doing. He only answers the questions he wants to leaving most of us in the dark.

Quote:

The challenge is that they are developing both a CPU core and the full chipset replacement. Both very large projects on their own. Hopefully V4/Core 3 comes out in the next couple of months. Will be quite interesting to see how it performs with this next generation.

The project is no doubt a lot of work. Gunnar has done a good job of keeping Amiga compatibility. The problem is making hardware and standards which the Amiga needs to grow into the future.

@WolfToTheMoon

You like to repeat that "PPC is dead" n9nsense while ignoring the fact that what most people think of as PPC is a subset of Power generation 4 or earlier.

Power is actively developed by IBM and Power 9 boards are available.
Raptor Engineering Talos II has two different single cpu configurations and Raptor has recently posted photos of a new MATX system under development.

Further, several NXP PPC processors are part of the company's long term support program.

Finally, itss 68K that is dead. Freescale/NXP licensed the manufacturing rights to the 68000 and 68020 to other companies, but does not produced 68K based cpus itself.

There is no supply source for large buys of the best 68000s, the '40 or '060, and supplies of the '030 are limited.

FPGA implementation of the 68K by hobbyist is what it is, a hobbyist project.

As the former manager of a company that built 68K based hardware in the '80s and '90s, most of which were sold to businesses (NOT hobbyists), I could not in good conscious sell this kind of hardware to anything except the hobbyist market.

The Vampire is a fascinating piece of hardware, BUT it's not comparable to a Power based systems.

It's like comparing a C64 to a PC.

@JimIgou

Quote:

FPGA implementation of the 68K by hobbyist is what it is, a hobbyist project.

There are quite a few commercially available 68k FPGA cores available, because that it what "the industries" do these days if they (for legacy reasons, typically) need a 68k.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@JimIgou

Quote:

You like to repeat that "PPC is dead"

I said Amiga PPC is dead.

Quote:

Power is actively developed by IBM and Power 9 boards are available. Raptor Engineering Talos II has two different single cpu configurations and Raptor has recently posted photos of a new MATX system under development.

That's great if you want to run Linux. There wont be any AmigaOS ports to Talos boards since there is no one left to do it.

_________________