Quote:

Hypex wrote: Sad to say but the OS is the only practical part left and that is in an always state of needing work.

A hardware design where every transistor counts is no longer practical?

Quote:

Well if you like to program it. It still beats x86-64 IMHO. But how is PPC a significant downgrade? 68K barely made it over the 100Mhz barrier. My X1000 runs at 1.8Ghz. That's a significant upgrade in peformance,

The 68060 design held up well against PPC designs even as they received die shrinks, especially low end designs like the 603(e). Higher performance PPC designs like the 604e used significantly more transistors for caches. Comparing performance between cores with more than a couple of die shrinks is pointless. PPC processors are being left in the dust by ARM designs on smaller die sizes today in the same way.

Quote:

Unfortunately, even using less clocks per operations, won't make it faster. An ASIC 68080 would be interesting to see. The free Google offer to fab an ASIC is sometihng they should consider right now even as proof as concept.

A core with less clocks per operation only makes it stronger. Better single core performance at a lower clock (saving energy) is only the Holy Grail of performance and energy efficiency.

Quote:

First, a program that converts 32-bit 68K ASM ro PPC32 ASM shouldn't be using 64-bit addresses anyway. Second, whatever is using 7 instructions, is rubbish. It only takes 5. Should only take 5. I do recall something particular about the G5 and 64-bit words, maybe the lack of new instrunctions to directly load the upper 64-bits. But, it should be; low word, high word, swap words, low word, high word; done. Third, any code needing to load in a full address, is badly written. Addresses on PPC should be loaded from an offset. Just like 68K did. A lot of Amiga compilers did produce redundant code that reloaded addresses in. Fourth. Dependng on how much data needs to be be loaded it can be optimised. Like MOVEQ on 68K PPC has similar instrunctions. Plus, it's obvious if large data needs to be loaded in then reading from memory using one intsruction may be better, especially for cached memory. I don't know if code does this.

Even a 5 instruction address load is bad as it requires mostly dependent instructions to build the address. This is not nearly as common as loading immediates into a register where fixed length RISC encodings also have a problem. Moving addresses and immediates into the data saves code and multiple instructions with RISC but now wastes valuable data cache and loads are more difficult to predict than building addresses or immediates in code. PPC is actually very good about *not* wasting data cache for immediates and addresses. MIPS, SuperH and even x86_64 are bad about eating up valuable data cache with immediate and address constants. Even some variable length encodings don't help reduce data cache usage or dependent instructions. For example, RISC-V compressed encodings have shorter forms of instructions which improve code density but still requires multiple dependent instructions to build large constants or wastes data cache while being less predictable than code built constants. The 68k can remove the MOVEQ+OP instructions with a sign extended immediate addressing mode which can compress larger immediates up to 16 bit instead of 8 bit. The bigger advantage is reducing the number of instructions where improvements in code density would be modest.

Quote:

Just like the copper! A true RISC CPU.

Simple RISC processors are fine when there isn't much code.

Quote:

We might as well stick to something way slower? Is one way of reading it. The both had no future 20 years ago. But now days I prefer the faster one. Even with an 060 and RTG my A4000 feels so 90's now.

Take your favorite 2.5 million transistor CPU from the mid 1990s and see if it does any better. You would probably be less happy with a PPC 603(e) today. The 68060 under 100MHz is still usable and even responsive running AmigaOS.

@matthey

Quote:

Take your favorite 2.5 million transistor CPU from the mid 1990s and see if it does any better. You would probably be less happy with a PPC 603(e) today. The 68060 under 100MHz is still usable and even responsive running AmigaOS.

I more happy with 603(e) than 060. It is faster.
And at least as fast and as comfortable as cheap Pentium from W95 era.

Last edited by ppcamiga1 on 10-Jul-2020 at 07:22 AM.

@matthey

Even if POWER is expensive it exist, is fast, has working FPU, has working MMU.

@A1200coder

Quote:

1. the CPU is m68k compatible

This is pure BS.
On Amiga we use C/C++.
cpu is just cpu nothing else.
"Classic" Amiga may work on any cpu that work in 32 bit big endian mode and it still will works and feel like Amiga from Commodore only better because faster.
Almost everything may be used like ppc,power, sparc, mips, itanium except x86,arm,risc-v that are low endian.
There is nothing special in m68k except it works in 32 bit big endian mode.
Last time I use assembler on Amiga in 1992 and don't want to use it again.
I learn C/C++ on Amiga. Ad it is still cool.

Quote:

2. chipset is compatible with OCS/ECS/AGA

It is stupid. Even amiga 1200 has faster cpu than blitter.
You have to have some software layer than handle things like this.
Hardware banging software works good only on Amiga 500.

Quote:

3. AmigaOS 3 compatible operating system

That's rigth. At least it have to have Amiga compatible gui and graphics.

@matthey

Quote:

A hardware design where every transistor counts is no longer practical?

That's a good idea. But recreating AGA is not practical for modern needs and would be expensive. Since I was comparing what is left of the Amiga now. My point was, with OS4 being the most updated variant of AmigaOS, it runs on hardware with common video and sound chips. Might not be fully x86 yet, as it's hanging onto that PPC, but the rest is commodity hardware.

Quote:

The 68060 design held up well against PPC designs even as they received die shrinks, especially low end designs like the 603(e).

I wonder how the 68K held up against the 88K that was to replace it?

Quote:

PPC processors are being left in the dust by ARM designs on smaller die sizes today in the same way.

And the design looks similar. I wonder how close a PPC JIT running on an ARM would fare? Obvious that ARM is the new favourite as a bit of development work is being put into it. Plus it helps a CPU to be used in consumer devices.

Quote:

Even a 5 instruction address load is bad as it requires mostly dependent instructions to build the address.

I agree that is bad. Even with 4 it would still be a lot. But, this is result of design contraints, so not a lot they could do. Even if it seemed backwards only being able to load in 16-bits at once.

Quote:

Moving addresses and immediates into the data saves code and multiple instructions with RISC but now wastes valuable data cache and loads are more difficult to predict than building addresses or immediates in code.

The problem would be data cache. To work around it would really need the immediate data in the instruction cache. If it was there it would almost have no penalty. My reasoning for that is; with CISC that data is interleaved with the instruction stream, but with RISC it could store it before or after a code block. The difference is where the data stored. Now, it won't make PPC use less code than CISC, but it would reduce loads to one instruction. I've had this idea for a while but don't know if could work in practice.

Quote:

Simple RISC processors are fine when there isn't much code.

Not much for the copper. Only 3 instructions and only 2 are commonly used. Thus why I call it RISC. Extreme RISC. The instruction format and data limits are very similar to PPC,

Quote:

Take your favorite 2.5 million transistor CPU from the mid 1990s and see if it does any better.

That would probably be a 68040. Even though the best I had was 68030.

Quote:

You would probably be less happy with a PPC 603(e) today

Certainly. But I still regret not getting it 20 years ago.

Quote:

The 68060 under 100MHz is still usable and even responsive running AmigaOS.

It would be. And that's double my 060 speed. But I couldn't survive using a sub Ghz CPU these days. Right now my real Amiga is a novelty. Would have liked to see the hardware continue into the modern age but it didn't happen.

Quote:

ppcamiga1 wrote: I more happy with 603(e) than 060. It is faster. And at least as fast and as comfortable as cheap Pentium from W95 era.

The 603 and 603e did end up being clocked higher than the 68060 but the 603 was a die shrink and the 603e two die shrinks smaller. The 8 stage pipeline and small 8kiB ICache and 8kiB DCache sizes should have made the 68060 easier to clock up if there was any desire to do so. The DEC Alpha 21064 out clocked PPC CPUs (up to 200MHz in 1993 when the PPC 601 was only operating up to 80MHz) and had a 7 stage pipeline and 8kiB ICache and 8kiB DCache. The 603 had the same cache sizes but only a 4 stage pipeline and the 603e doubled the cache sizes while remaining only 4 stages. The 6 stage 604e had more trouble clocking up than the 603e probably because of the 32 kiB ICache and 32kiB DCache sizes where it likely would have benefited from an on chip L2 cache and smaller L1 caches (Pioneered by the Alpha 21264). Early Motorola/Freescale PPC processors did *not* clock up well do to their shallow pipelines and large caches. Later PPC processors which did clock up had deeper pipelines, multi-level on chip caches and/or used much smaller die sizes than the 68060.

The 603(e) is also a dog because of its design. There is only one integer unit and the load/store unit can't do very complex addressing mode calculations. The 68060 can do several times the amount of integer calculations in a cycle than the 603(e). Address results are often known several cycles earlier which more than offsets the simple OoO of the 603e moving loads earlier. The 68060 was still competitive with the 603e at the same clock speed when the 603e had a two die shrink advantage!

Quote:

ppcamiga1 wrote: Even if POWER is expensive it exist, is fast, has working FPU, has working MMU.

That is an advantage over some of these cheap embedded PPC chips using an older process. How many of your friends and family will pay $2000 U.S. for a complete POWER system though?

Quote:

Hypex wrote: That's a good idea. But recreating AGA is not practical for modern needs and would be expensive. Since I was comparing what is left of the Amiga now. My point was, with OS4 being the most updated variant of AmigaOS, it runs on hardware with common video and sound chips. Might not be fully x86 yet, as it's hanging onto that PPC, but the rest is commodity hardware.

AGA with chunky RTG support can go out HDMI with sound. AGA may even have some applications overlayed over the RTG. Cost is low because the logic is simple. The $45 U.S. FleaFPGA could simulate ECS+68000 and only about half of the cost was components including the FPGA. The logic for AGA in an ASIC with even a mid-performance CPU wouldn't be worth mentioning. The extra pins and lines would add some cost but would be cheaper than adding an extra chip to the board. It is 3D GPUs which are expensive to add, especially if modern and/or higher performance.

Quote:

I wonder how the 68K held up against the 88K that was to replace it?

The in order 88100 is perhaps more comparable to a 68040 (33MHz max in 1989) except needed companion chips for MMUs and caches which was neither popular, good for performance or cheap (the 68040 was not a great design either). The superscalar OoO 88110 (50MHz max in 1992) was a huge upgrade in performance and is comparable to the 68060 even though it came first and never reached the die size of the 68060. Mitch Alsup said they were designed independently even though there are a few similarities. The 88110 is a shallow pipeline design that is only 2 issue but is powerful with 10 independent execution units (certainly more powerful than the 603 design). It is funny that Motorola/Freescale exchanged one shallow pipeline OoO RISC architectures for another and dropped the 68060 with deeper pipeline and more efficient cache usage which was the best candidate for clocking up.

Quote:

And the design looks similar. I wonder how close a PPC JIT running on an ARM would fare? Obvious that ARM is the new favourite as a bit of development work is being put into it. Plus it helps a CPU to be used in consumer devices.

ARM AArch64 should be able to emulate most PPC instructions with a single instruction. Addressing modes should not be a problem but there are differences. Some AArch64 instructions only have 12 bits of immediate which can be shifted to a variety of places where PPC has 16 bits but can be swapped into fewer locations in the register (pure RISC would typically need 7 instructions to construct a 64 bit immediate). AArch64 often has more encoding bits for branch displacements which is helpful for 64 bit addressing reducing the need for branch trampolines.

Quote:

I agree that is bad. Even with 4 it would still be a lot. But, this is result of design contraints, so not a lot they could do. Even if it seemed backwards only being able to load in 16-bits at once.

Immediates and address generation requiring multiple dependant instructions to load in a register is a self imposed constraint from failing to adopt variable length instruction encodings. Sadly, most variable length RISC ISAs like RISC-V and Thumb2 failed in this regard too. The x86_64 ISA can use large immediates and displacements but with a lot more restrictions than it should have often requiring multiple instructions as well.

Quote:

The problem would be data cache. To work around it would really need the immediate data in the instruction cache. If it was there it would almost have no penalty. My reasoning for that is; with CISC that data is interleaved with the instruction stream, but with RISC it could store it before or after a code block. The difference is where the data stored. Now, it won't make PPC use less code than CISC, but it would reduce loads to one instruction. I've had this idea for a while but don't know if could work in practice.

Yes, immediates in the ICache and fetched with predictable instruction fetch are preferable to loading in the DCache. Only high end cores have dual ported or interleaved data accesses which support more than one DCache read per cycle. Reading immediates from DCache not only wastes the DCache but can bottleneck the whole core from reading data. There is no reason to choose the lesser of two evils between multiple dependent instructions and bottlenecking the DCache. Supporting longer instructions with a variable length instruction set isn't that hard.

Quote:

It would be. And that's double my 060 speed. But I couldn't survive using a sub Ghz CPU these days. Right now my real Amiga is a novelty. Would have liked to see the hardware continue into the modern age but it didn't happen.

A 68060 is a little lean for modern software but it missed most of Moore's Law. The 68060 has 2,500,000 transistors while a POWER 9 has 8,000,000,000 transistors and an iPhone 11 Pro A13 SoC has 8,500,000,000 transistors. Not really in the same class.

@ppcamiga1

Quote:

This is pure BS. On Amiga we use C/C++.

This really depends. Some use and some do not. Please mind that the most successful Amiga game titles were made in asm. At least critical parts should be written in asm.

Quote:

It is stupid. Even amiga 1200 has faster cpu than blitter. You have to have some software layer than handle things like this. Hardware banging software works good only on Amiga 500.

Chipset should be there, as we do not want emulate old Amiga HW on a new Amiga. And at least with the FPGA, we do not have the power to do even that properly. The blitter can still be useful with a fast CPU as it can be used in parallell with CPU in some cases. In a 3D game you can use blitter to clear previous frame, while the CPU is doing something else adding to performance.

Improved chipsets can of course be made. In Vampire there are 16 audio channels with better audio quality and also sprites with better specs than on AGA. And new screenmodes with better resolutions. And CPU has MMX-instructions. Step by step, more additions can be made, like making some 3D gfx support also.

Also having a 1 GHz+ 68k would make a very unbalanced system, if there is no 3D acceleration around. This clearly needs more work, we can't just accept industry standards and ready made GPUs, as they do not integrate with Amiga custom chips. We need something simpler that still works well enough for our needs.

@matthey

Quote:

The in order 88100 is perhaps more comparable to a 68040 (33MHz max in 1989)

Spec CPU92 numbers:

25 MHz MC68040
13.5 SpecInt92 (integer speed)
9.9 SpecFp92 (floating point speed)

33 MHz MC68040
17.8 SpecInt92
12.9 SpecFp92

25MHz MC88100
21.2 SpecInt92
14.5 SpecFp92

33MHz MC88100
27.7 SpecInt92
18.8 SpecFp92

50MHz MC88110
54.0 SpecInt92
62.2 SpecFp92

66MHz 603 Power PC
60.6 SpecInt92 (256 kB L2) or 63.7 SpecInt92 (1 MB L2)
60.7 SpecFp92 (256 kB L2) or 64.9 SpecFp92 (1 MB L2)


(full benchmark reports available at performance.netlib.org)

@matthey

Quote:

That is an advantage over some of these cheap embedded PPC chips using an older process. How many of your friends and family will pay $2000 U.S. for a complete POWER system though?

And how many new people you get when all you have to offer is something worse than cheap pc from Windows 95 era?

Sorry for not reading the whole thread. But I am missing x64. The plattform is cheap and powerful. We could could buy a stack of 100 or 200 with voulume discount.Maybe watching more for singlecore performance. All same HW Radeon GPU and voilat we have a great systrem.

Or why not choosing the new Apple plattform? ;) ;)

@ppcamiga1

Quote:

And how many new people you get when all you have to offer is something worse than cheap pc from Windows 95 era?

In which reality there is more NG users than Classic users? I wouldn't be surprised if number of existing Vampire users exceeds amount of OS4 users. Market for people paying €500 for motherboard with slower CPU than Raspberry Pi is even more limited.

@A1200coder

Quote:

Please mind that the most successful Amiga game titles were made in asm.

For Amiga 500 almost thirty years ago.

Quote:

At least critical parts should be written in asm.

On any Amiga faster than Amiga 500 C is good enough.

@ppcamiga1

Quote:

ppcamiga1 wrote: @A1200coder Quote: Please mind that the most successful Amiga game titles were made in asm. For Amiga 500 almost thirty years ago. Quote: At least critical parts should be written in asm. On any Amiga faster than Amiga 500 C is good enough.

Not with less than 1 GB of RAM. That's what it takes to run GCC 6.5b cross compilers. Not to mention that modern compilers still do rather brain-dead things from time to time.

What you guys ought to discuss, is which modern CPU is best at 68k emulation in terms of price, power usage and performance. Because that’s ultimately what we will be using them for.

Huh, why did this end up in this thread? I posted in the apple thread... oh well.

Last edited by kolla on 11-Jul-2020 at 02:43 PM.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@Rose

And how many of them are new people especially new developers?

aros on rpi do not provide integration with old 68k software so your comparison is simply dumb.

@Samurai_Crow

Quote:

Not with less than 1 GB of RAM.

Pure BS.
Use SAS C or older but still good gcc 3.x.

Quote:

pavlor wrote: Spec CPU92 numbers: 25 MHz MC68040 13.5 SpecInt92 (integer speed) 9.9 SpecFp92 (floating point speed) 33 MHz MC68040 17.8 SpecInt92 12.9 SpecFp92 25MHz MC88100 21.2 SpecInt92 14.5 SpecFp92 33MHz MC88100 27.7 SpecInt92 18.8 SpecFp92 50MHz MC88110 54.0 SpecInt92 62.2 SpecFp92 66MHz 603 Power PC 60.6 SpecInt92 (256 kB L2) or 63.7 SpecInt92 (1 MB L2) 60.7 SpecFp92 (256 kB L2) or 64.9 SpecFp92 (1 MB L2) (full benchmark reports available at performance.netlib.org)

The 88100 performed better than I expected. Integer performance of the 88110 could be better but maybe it doesn't have the external L2 companion chip and L1 caches are on the small side for quicker cache accesses. Floating point performance of the 88110 is good showing that the 80 bit FPU like the 68k FPU was not a problem for performance. As I expected, the 88110 design is easily outperforming the PPC 603 especially considering the 603 has two die shrinks on it and probably newer higher performance memory for the external L2. The 88110 was a high performance design at the time where the 603 was a later low power design. The in between 68060 design was balanced which ended up with better performance and lower power than expected due to cache efficiency and ISA advantges with the focus on integer performance rather than floating point performance. It's interesting to compare these diverse CPUs and see how quickly designs and processes were changing at that time. The simple shallow pipeline RISC designs changed quickly as high clocked deeper pipelined Alpha cores made core designers rethink their designs even though the Alpha designs were too extreme to be practical.

Last edited by matthey on 11-Jul-2020 at 08:40 PM.

@ppcamiga1

SAS/C is lax on register loading optimizations. It isn't even in the same league as Bebbo's GCC 6.5b compiler.

@ppcamiga1

Quote:

There is nothing special in m68k except it works in 32 bit big endian mode.

There's a document from Haynie that talks about HP RISC being chosen for that reason too.

Quote:

Almost everything may be used like ppc,power, sparc, mips, itanium except x86,arm,risc-v that are low endian.

After reading about Itanium. I would have been happy with that Intel inside a new Amiga. It might have had Intel inside but it wouldn't be PC.

As to x86, actually, it can read and write in big endian for a while now. Just like PPC can in little endian. But x86 has no big endian mode.

Quote:

Last time I use assembler on Amiga in 1992 and don't want to use it again.

Why not? It was still 68K in those days and those days were cool. Have you tried PPC assembler? Slightly harder leaarning curve. But I'm happy to leave it for C.

Quote:

It is stupid. Even amiga 1200 has faster cpu than blitter.

And unlike blitter CPU is 32-bit. Also it depends what the blitter is being used for. Using CPU to scroll instead of blitter or screen X/Y? Nah, what a waste. A straight blit copy replacing tiles? Sure. A masked blit with edge trimimng into random X/Y? Well that's harder; needing to mask off edges, mask off bitmap data and shift data. A line draw operation? Well you could use CPU, to split it off into single pixels writes for angles, but it seems wastetful when dedicated hardware can do it.