Do you approve of PPC (in some form) as the future of Amiga?

[Hammer]

We have the problem of endianess http://en.wikipedia.org/wiki/Endianness it is unlikely that amigaos will ever be ported to x86 and boot natively.That thing wont be an amiga.PPC can change the endianess http://en.wikipedia.org/wiki/PowerPC#Endian_modes but i dont think it would be easy to port it to x86.So x86 is definitely out of the question for me.
Also from the same page Endianness and operating systems on architectures
(SNIP)

Read http://emumiga.com/about/

Another reason is, we want Amiga applications to be run as native applications in AROS, or first class citizens, if you like. An Amiga application should be able to talk to the AREXX port of an AROS application, and the other way around. When the Amiga application calls a library, it will automatically be a native AROS library, running some Amiga applications at close to AROS speeds, for instance when using datatypes.

[Hammer]

From http://obligement.free.fr/articles_traduction/itwbarthel_en.php

"The high price of the AmigaOne X1000 seems to be an argument, for lots of amigans, to not buy the machine. A solution to sell lot more copies of AmigaOS could be an x86 version. What is your opinion about that?

In this small market price is always an issue. The kind of power the X1000 provides, for such a small customer base, naturally results in a high price. As things stand today, you cannot make this kind of gear in sufficiently large enough volume to bring down the cost and consequently the price.

I consider the x86 path a pipe dream. AmigaOS has no platform/porting layer: it is hardwired to a big-endian host platform, not just the fundamentals but also its data structures. I would say that the chances to see AmigaOS run on an ARM are much higher than to see it run on an x86 family processor. If you wanted to make it work on an x86 host, you would have to throw out all existing Amiga software designed to run on the 68k platform, much of which is still useful today (I would go so far as saying that it is not just useful, it is necessary). You would have to throw away much of the operating system and replace it.

Even if you were to make all of that happen as part of an x86 port, you would have to make significant sacrifices. I doubt that any of these would result in a viable product."

Read http://emumiga.com/about/

[Hammer]

Reading through a few comments on here.  As far as I understood it PPC has a smaller instruction set than x86 and like for like will run much faster than an x86.

PowerPC G3 has more instructions than Pentium II i.e. refer to http://arstechnica.com/cpu/4q99/risc-cisc/rvc-5.html

---
From http://en.wikipedia.org/wiki/Reduced_instruction_set_computing

A common misunderstanding of the phrase "reduced instruction set computer" is the mistaken idea that instructions are simply eliminated, resulting in a smaller set of instructions. In fact, over the years, RISC instruction sets have grown in size, and today many of them have a larger set of instructions than many CISC CPUs.[6][7] Some RISC processors such as the INMOS Transputer have instruction sets as large as, say, the CISC IBM System/370; and conversely, the DEC PDP-8 – clearly a CISC CPU because many of its instructions involve multiple memory accesses – has only 8 basic instructions, plus a few extended instructions.

The term "reduced" in that phrase was intended to describe the fact that the amount of work any single instruction accomplishes is reduced – at most a single data memory cycle – compared to the "complex instructions" of CISC CPUs that may require dozens of data memory cycles in order to execute a single instruction.[8] In particular, RISC processors typically have separate instructions for I/O and data processing; as a consequence, industry observers have started using the terms "register-register" or "load-store" to describe RISC processors.

Some CPUs have been retroactively dubbed RISC — a Byte magazine article once referred to the 6502 as "the original RISC processor" due to its simplistic and nearly orthogonal instruction set (most instructions work with most addressing modes) as well as its 256 zero-page "registers". The 6502 is no load/store design however: arithmetic operations may read memory, and instructions like INC and ROL even modify memory. Furthermore, orthogonality is equally often associated with "CISC". However, the 6502 may be regarded as similar to RISC (and early machines) in the fact that it uses no microcode sequencing. However, the well known fact that it employed longer but fewer clock cycles compared to many contemporary microprocessors was due to a more asynchronous design with less subdivision of internal machine cycles. This is similar to early machines, but not to RISC.
----------------------------------------------------

The Concept of the Instruction Set Architecture from http://arstechnica.com/cpu/2q00/x86future/isa-future-2.html

RISC vs. CISC: the Post-RISC Era from http://arstechnica.com/cpu/4q99/risc-cisc/rvc-1.html

RISC and CISC, Side by Side from http://arstechnica.com/cpu/4q99/risc-cisc/rvc-5.html

RISC vs. CISC Conclusion from http://arstechnica.com/cpu/4q99/risc-cisc/rvc-6.html

Both the Athlon and the P6 run the CISC x86 ISA in what amounts to hardware emulation, but they translate the x86 instructions into smaller, RISC-like operations that fed into a fully post-RISC core.  Their cores have a number of RISC features (LOAD/STORE memory access, pipelined execution, reduced instructions, expanded register count via register renaming), to which are added all of the post-RISC features we've discussed.  The Athlon muddies the waters even further in that it uses both direct execution and a microcode engine for instruction decoding.  A crucial difference between the Athlon (and P6) and the G4 is that, as already noted, the Athlon must translate x86 instructions into smaller RISC ops.

[Hammer]

MorphOS 3.0 on Apple PowerBook G4. http://www.youtube.com/watch?v=V89YwHFoXyw

[Hammer]

What about the ppc in PS3 ?

On normal linux apps, the CELL's PPE at 3.2Ghz was benchmarked to be around PowerPC 970 at 1.6Ghz. The PPE vs PowerPC 970 relationship is like Intel Atom vs Intel Core 2.

CELL's PPE is closer to Intel Atom i.e. in-order-processing and dual instruction issue per cycle design.

[Hammer]

Really? My experience was that the PS3 with Linux was alot slower for "normal linux apps" than my 1.33GHz G4 iBook, also when not using swap at all.

http://www.xtremesystems.org/forums/archive/index.php/t-125219.html

Lack of direct access to NVIDIA RSX and 256MB ram for PPE didn't help PS3's linux situation.

[Hammer]

X86 makers:

-Intel
-Amd
-Via?

PowerPC makers

-IBM
-Freescale
-Amcc
-Toshiba
-Rapport inc
-Agnilux/google?

PowerPC wins

X86 makers:

AMD
Advantech (e.g X86 SoC)
D&MP (e.g Vortex86 Series SoC )
Intel
NVIDIA (e.g. ULI M6117C)
RDC (e.g R8610 )
VIA
ZF Micro (e.g. ZFx86 SoC)

Intel has licensed Intel Atom to TSMC.

http://en.wikipedia.org/wiki/List_of_x86_manufacturers

[Hammer]

If they don't get 150MHz this year, they probably will next as the speed of fpgas increase and the price drops. There are fpgas that are fast enough now but they cost a lot of money. The 68k did often outperform the early PPC processors. Even the 68040 outperformed the early PPC processors on the early MACs. Amiga users with 68060 and Shapeshifter or Fusion had the fastest MAC for about a year. Apple made the later MAC OS incompatible with the 68060 because of it. MAC OS 7 worked great with the 68060 and then MAC OS 8 didn't for some odd reason. An fpga N68k isn't going to wow people or steal x86 market share but it will probably be fast enough to impress Amiga users still using the classic and fast enough for general computer needs. That's enough for me. I'm not opposed to PPC Amigas. I would like to see 68k for the low end and laptops and PPC for the high end and desktops. The attitude of Hyperion has turned me off though. I prefer the openness of Natami and AROS (but don't care for the x86 focus of AROS).

Here's what an IBM engineer has to say about the 68060 and PPC...

"With 2 instructions per clock and excellent multiplication and branch performance, the 68060 performs very good. Depending on the workload the 68060 can even outperform similar clocked 60x/G2/G3 PowerPC CPU."

"Actually the 68060 is faster in multiplication than many PowerPC.
The PPC G2 (603) and G3 CPU need 5 cycles for a multiplication.
Which means a 100 Mhz 68060 achieves the same multiplication performance as an 250 Mhz G3."

http://www.natami.net/knowledge.php?b=4¬e=2418

Let's look at some 68k code to see what is so great about the 68k. Let's take a simple 68k memory copy with size (longwords) in d0...

.loop:
 move.l (a0)+,(a1)+
 subq.l #1,d0
 bcc.b .loop

Let's say we don't know the alignment of the data either. This copies 1 longword/cycle with data aligned and is 6 bytes. If data is unaligned this is still pretty good. Now write that on PPC with anywhere near the performance. Don't let the old outdated 68060 with tiny little cache and only 4 bytes of instruction fetch/cycle DESTROY. I'll even give you a few hints. You better align the data first or the performance is really bad. You will need twice as many instructions to duplicate what's above. You will need to use an unrolled loop (wasting more code) and preload the cache. If you do all that optimally, you are still likely slower than the 68060 . No wonder PPC needs all those GHz.

K8/K10 and Core 2/i3/i5/i7 can process IMUL(32bit) at every cycle(1 cycle througput) with 3 cycle latency.

Core i3/i5/i7 can process IMUL (64bit) at every cycle (1 cycle througput) with 3 cycle latency. K8/K10 and Core 2 has can process IMUL (64bit) in 2 cycles (2 cycle througput)  with 4 cycle latency. To hide the latency, factor in the pipeline and it's spectualive execution design.

Per instruction benchmarks doesn't show the whole picture in regards to overall performance i.e. use some proper application benchmarks.

....
This means that on the x86 you need to work constantly with variables on the stack. This limits the overall performance of the x86 quite a lot. All INTEL chips can at best do 1 stack operation per clock. This means as they often have to work on the stack your average instructions per clock goes down to 1.x.
That the x86 has to work with the stack constantly makes it very hard for the x86 to effective use more ALUs to increase performance

As for X86's stack arch issue, AMD K10 includes Sideband Stack Optimizer hardware while Intel Core includes Stack Pointer Tracker hardware.

From http://www.xbitlabs.com/articles/cpu/display/amd-k10_5.html

"Sideband Stack Optimizer unit tracks the stack status changes and modifies the instructions chain into an independent one by adjusting the stack offset for each instruction and placing sync-MOP operations (top of the stack synchronization) in front of the instructions that work directly with the stack register. This way instructions working directly with the stack can be reordered without any limitations"
--
This amounts to JIT(Just-In-Time) optimizer on hardware.

On Intel Core i3/i5/i7

Stack Pointer Tracking (SPT) implements the Stack Pointer Register (RSP) update logic of instructions which manipulate the program stack (PUSH, POP, CALL, LEAVE and RET) within the IDU. These macro-instructions were implemented by several micro-ops in previous architectures.

The benefits with SPT include using
+ a single micro-op for these instructions improves decoder bandwidth,
+ execution resources are conserved since RSP updates do not compete for them,
+ parallelism in the execution engine is improved since the implicit serial dependencies have already been taken care of,
+ power efficiency improves since RSP updates are carried out by a small hardware unit

---
http://www.chip-architect.com/news/2001_10_02_Hammer_microarchitecture.html

"This is for instance the case in the ESP Look Ahead Unit that allows among other things that consecutive PUSHes and POPs to and  from the stack can be executed simultaneously"

PS; 2001 block diagram resembles AMD Bulldozer block diagram.

[Hammer]

The principles of north- and southbridge are in principle still inferior to a theretical modern day custom chipset design.
More flexible, yes, but also bottlenecks. Pumping up the bitrates still to overcome its deficiencies. Not something a tech head can be enthusiastic about.

Why is it inferior? The old Amiga 500 has Paula, Angus, Denise, Gary to provide chipset services. http://en.wikipedia.org/wiki/Amiga_custom_chips

In terms of chipset services, what special about the old Amiga custom chipset?


Intel Core i3/i5/i7 doesn't have the standard PC northbridge chip i.e. PCI-Express 2.0 lanes for graphics is built into the CPU.

[Hammer]

I'm trying to figure out what I'm doing these days that simply could never be done on a 68060 -- seeing that it's fine for nonlinear video, etc.

MPEG2/H264 encoding in HD would be slow on the 68060. Today it's SMP and GpGPU.

[Hammer]

I seem to recall that the only time the floating point performance really took off for the mac was in a few very select and very highly optimised benchmarks using photoshop.

With G5, Apple didn't factor AMD's K8 Athlon 64 i.e. refer barefeat.com's benchmarks.

[Hammer]

To answer the OP, yes I do approve, in the form of MOS, but by now we must see that such discussions are fruitless, start flame wars and lead to ignorant comments like when Kolla called me a dumbass because of my opinion of the iMica.

Reasons why MOS, OS4 and Classic will probably never be x86.

Bye Bye to all your favorite apps native support, they all need big endian for native support of any kind

Making it x86 would involve twice the work, as its assembly code is a mess, and all our API, ABI and system calls taht have bits of ASM would all be bye bye, useless

Even if x86 was the main platform, do you know theres over 20 N/S bridge combinations currently produced?

Your average Linux or Mac geek (the market we probably would be attracting) would be pissed at:
lack of memory protection
Lack of security and privacy systems.
Unfamiliar controls, needing to learn whole new syntax (AmiDOS and derivatives)

Also, realize a 1.5 Ghz G4 beats a 3.2 GHz Pentium 4 in general performance, a PPC will give you twice (or more) performance per cycle due to its RISC and ability to execute instructions faster and more efficiently

Therefore, an x86 switch by any of those listed is HIGHLY unlikely.  Before these happen, Ronald Reagan would come back from the dead, or Kennedy.

In normal desktop benchmarks, PPE at 3.2Ghz in PS3 performs like PowerPC 970 @1.6Ghz. PowerPC ISA vs X86 ISA irrelevant i.e. what matters is the hardware implementation.
 
Since you made a claim on PPC vs X86 I'm restarting PowerPC vs X86.

http://www.barefeats.com/pbcd.html

Apple MacBook Pro (2.0GHz Core 1 Duo)/Apple MacBook Solo  (2.0GHz Core 1 Solo)  
vs
Apple PowerBook (PowerPC 7447A 2.0GHz upgrade)
vs.
Apple Power Mac (Dual Core PowerPC 970 2.0Ghz)  







We are not factoring Intel Core 2, AMD Phenom II and Intel Core i3/i5/i7 based PCs. AMD Bulldozer is already in engineering release mode i.e. same state as X1000 beta test.

http://www.barefeats.com/imcd3.html
iMac C2D/2.33 = 24" iMac Core 2 Duo 2.33GHz
iMac C2D/2.16 = 20" iMac Core 2 Duo 2.16GHz
iMac CD/2.0 = Jan 2006 - 20" iMac Core Duo 2.0GHz
iMac G5/2.1 = Oct 2005 - 20" iMac G5/2.1GHz 'iSight'
iMac G5/2.0 = May 2005 - 20" iMac G5/2.0GHz 'ALS'
(All test systems had 2GB of memory)





http://www.barefeats.com/g4up2.html
MAXPower G4/7448 Upgrade versus similarly clocked Macs

PM G5 2.0 MP b = Power Mac G5/2.0GHz "June 2003" with Radeon X800 XT
PM G5 2.0 MP a = Power Mac G5/2.0GHz "June 2003" with Radeon 9800 Pro SE
iMac CD 2.0 = Intel iMac Core Duo 2.0GHz with Radeon X1600
iMac G5 2.1 = iMac (Solo) G5/2.1GHz "iSight" with Radeon X1600 XT
iMac G5 2.0 = iMac G5/2.0GHz "ALS" with X1600 XTz
7448 1.8 MP = MAXPower Dual G4/1.8GHz 7448 Upgrade in a "QuickSilver 2002" Power Mac with Radeon 9800 Pro
7448 2.0 SP = MAXPower Solo G4/2.0GHz 7448 Upgrade in a "QuickSilver 2002" Power Mac with Radeon 9800 Pro
7447A 2.0 SP = GigaDesigns Solo G4/2.0GHz 7447A Upgrade in a "QuickSilver" Power Mac with Radeon 9800 Pro
7455 1.42 MP = Dual G4/1.42GHz 7455 "FW800" Power Mac with Radeon 9800 Pro
Quick 1.0 MP = Power Mac Dual G4/1.0GHz "QuickSilver 2002" with Radeon 9800 Pro
Quiick 800 MP = Power Mac Dual G4/800MHz "QuickSilver" with Radeon 9800 Pro
The G4 Power Macs had 1.5GB of RAM; The other Macs had either 1.5 or 2GB of RAM.
All Macs were running OS X 10.4.9.






http://www.barefeats.com/harper.html
Mac Pro 3.2GHz 'Harpertown' versus other Mac towers

Harper = "early 2008" Mac Pro "Harpertown"
Clover = "apr 2007" Mac Pro "Clovertown"
Wood = "aug 2006" Mac Pro "Woodcrest"
PM = Power Mac (last version with PCIe slots)





64bit GEEKBENCH 2 benchmark test on all Macs

[Hammer]

Actually I was thinking prior to the G5's release. The only thing that the Mac offered in terms of performance that was anywhere near close to PCs of the day were those highly focused photoshop benchmarks - on anything else the G4 got spanked badly by both intel and AMD.

In responds to Apple's G5 claims

http://www.pcworld.com/article/112749-8/64bit_takes_off.html
Athlon 64 vs. Apple G5 Systems: Not Even Close (chart)
Apple Power Macs did well on Photoshop, but the 64-bit AMD-based systems won handily on most tests.


AMD K8 Opteron 246 @2.0Ghz vs Power Mac G5 (two IBM PowerPC 970 @ 2.0GHz).

Benchmark Chart from http://www.pcworld.com/zoom?id=112749&page=8&type=table&zoomIdx=1
The AMD64 boxes debunking Apple's G5 claims i.e. 1 CPU vs 1 CPU and 2 CPU vs 2 CPU.

Intel Pentium IV is an easy target.

[Hammer]

Tbh I didn't really follow the G5 much beyond it's launch. It's interesting to see that even afterwards, whilst some of the gap between PPC and x86 was gained, it was still on the trailing edge of performance, except, as before and as you noted: Photoshop.

RE the PIV, a power hungry, hard to cool beast it may have been, but it could still put the kosh to a G4 or a G5.

?? The chart shows AMD64 boxes beating G5 systems in photoshop...

PowerMac G5 (two PPC 970 @ 2Ghz, two cores)
18 sec for 50 MB test
51 sec for 150 MB test

Polywell Polystation Two (K8 Opteron 246 @2Ghz, two cores)
17 sec for 50 MB test
47 sec for 150 MB test

[Hammer]

You're comparing 2003 machines to 2006 machine and are what - surprised?

There are plenty of benchmarks on this, but x86 are stronger in some areas (branchy integer stuff) while PPCs are better in different areas FP and especially Altivec.

Depends on the FP workload. Did you miss Cinebench benchmarks?  SSE is missing some non-desktop application targeted SIMD instructions.

AMD K8 already has 128bit wide FADD SSE and built-in memory controllers. Each of K8's FADD, FMUL and FMISC has it's own instruction issue ports.

Apple were very clever with the timing of their switch because it meant they went from lat year's PPCs to next years x86s and of course the x86s were faster.

Actually according to the benchmarks published at the time there wasn't that much of a difference between them, in fact the G4s could rip music faster than the first mac x86s.

One problem with testing CD ripping speeds is the speed of the optical drives involved.

Did you factor in iMovie HD benchmarks?

Apple MacBook Pro (2.0GHz Core 1 Duo)/Apple MacBook Solo (2.0GHz Core 1 Solo)
vs
Apple PowerBook (PowerPC 7447A 2.0GHz upgrade)

It was only after the Core2Duos appeared that a clear gap emerged, but by then development of desktop PPCs had already stalled.

Have you forgotten AMD64? The topic here is not about Apple's switch to Intel i.e. the topic is PowerPC vs X86(includes AMD64)