Power 7 CPU - 8 cores

[matthey]

I think IBM gave up the desktop when they realised how small the profit margins were going to be. Better to make CPUs for high-end servers, mainframes, routers/switches/networking and automotive usage all of which have much larger profit margins.

And collect U.S. Government charity handout money to oligopolies to fund their research and development ($244 million from DARPA). We love and support our big business oligopolies/monopolies in the U.S. even though our hypocritical politicians (all the way to the top) say they are for small business.

If the x1000 can sell for $3000, maybe Hyperion should have the Power 7 thrown in a computer. They could bring out the x10000 supporting 1 of 32 threads+cores and sell it for $30,000 with the AmigaOS 4 faithful lining up.

[matthey]

"DEC MicroPDP-11/23+ (15MHz, 32MB HD, 256KB RAM)"
 
Love that one, John.
I was interested in that CPU family before there were pre-built computers.
 
16bit before the 8bit IBM PC was introduced.

The 68k is old and it was heavily influenced by the PDP-11/VAX-11 which would be ancient and quite an innovative design back then. I think it would be difficult to make fast on modern hardware but I think the 68k could be modernized and run well enough. A modern 68k would be the easiest to use and have the best code density of any "modernized" CPU (x86, ARM and PPC are old designs too). I think it could compete with ARM for small electrical devices. What do you think of this modernized 68k ISA:
 
OpenOffice Writer
http://www.heywheel.com/matthey/Amiga/68kF_PRM.odt

PDF
http://www.heywheel.com/matthey/Amiga/68kF_PRM.pdf
   
html
http://www.heywheel.com/matthey/Amiga/68kF_PRM.html

I know there is no multiprocessing or caching instructions at this point but they are more dependent on the implementation. What do you like and dislike? Any love for the 68k besides me?

[matthey]

@zylesea
I'm aware of the ColdFire. Freescale weakened and stripped the 68k so much that they ruined it and lost most of the 68k supporters and programmers. They did finally add some useful instructions back in but what a feeble effort. I guess they were successful in their marketing attempt to drive 68k people to the PPC (or ARM and x86 more likely). I was talking about a robust powerful 68k ISA. The 68kF ISA I showed would increase the code density considerably and remove many short branches while allowing for nearly 100% backward compatibility of the 68k family. The CF accomplished none of these.

Well Matt,
Unless there was a lot of revision (and  I love the 68K and used to sell 68K based hardware), no contest.
An in order, cacheless processor vs a modern CPU?
We'd lose.

I think full OoOE is wasteful, especially for an electricity conserving device. Doing a few instructions like division out of order can make sense though. The 68060 is a proven excellent processor and could be scaled up with today's tech, modernized and enhanced. The 68kF has a lot of what I'm talking about. I need to finish the addressing modes and add floating point. The 68k has some great advantages that Motorola/Freescale never explored and instead through away.

[matthey]

@Iggy
Almost every choice made with the 68kF improves code density. I would expect 5%-15% better code density than 68020 or ColdFire code. The ColdFire has some code density improvements (MVS/MVZ, MOV3Q, BYTEREV, etc.) but they are offset by what they took away (Byte and Word instruction sizes, addressing modes, bitfield instructions, etc.)

[matthey]

The only problem with the argument about the importance of code density is memory is cheap.

Code density matters for small electrical devices especially with batteries. That is why I talked about competing with ARM and not x86 on the desktop. I'm thinking of laptops, pads, netbooks, smart phones, embedded devices, fanless desktops where ARM leaves something to be desired and x86_64 is like taking a MAC truck to the grocery store. Better code density also means more instructions in the instruction cache and a smaller instruction fetch is needed. Less memory usage is still a small advantage in general, more so on low end electrical devices.

Just use I7s , much better bang for buck.

Can you show me how to program utilizing all the cores? I have a Windows component bug with the file sharing (which is used) at work that crashes. Can you disassemble the component if I send it to you and fix it for me? While you are at it, can you fix our GHz computers from stopping and being unresponsive for several seconds? I suppose I can upgrade to the i7 and it will probably be fast until Windows 9 comes out (the fix for the Windows 8 every other generation mistake). We still use Windows XP so we shouldn't need an i7 CPU but Windows slows down the more and more we use it. Can you fix that too? Intel can always quadruple the number of cores, move to 128 bits and add a few terrabytes of memory so we can finally have CPU Nirvana since we couldn't get there by GHz alone. I would rather have an efficient flexible CPU that I can program than a high latency, resource hogging DSP monster of a CPU in the same way as I would rather drive a nimble little sports car with 300HP than a fire breathing MAC truck with 3000HP. Unfortunately, most people choose the MAC truck because it's faster in a straight line for a few seconds (in a straight line on an open road) and 3000HP is a much bigger number than 300HP. There aren't very many true CPU connoisseurs any more just like sports car connoisseurs are a dying breed too .

[matthey]

None of that is down to the CPU. You'd encounter the same issues running a super-68k CPU because it's software. When you don't have to deal with a modern OS and the thousands of processes it has to manage then you can get plenty of performance out of ANY of these architectures.

I can debug, disassemble, fix bugs and optimize code in the AmigaOS because the CPU is easy to use and the code is small. Programming is easier on a flexible low latency CPU than a DSP/SIMD like high latency CPU also. The CPU does matter to me at least. Give me a superscaler N68070@500MHz using the 68kF ISA and I'll be happy .

Honestly everyone goes on about AmigaOS vs Windows 7/8 but frankly AOS does absolutely nothing in comparison to it. If, and it's obviously a hypothetical if, AmigaOS development had continued in parity with Windows and x86 over the years then we'd all be whining about the same things. It's not some wonder-CPU-architecture that made AOS usable, it was simply because it was extremely primitive compared to modern operating systems.

The AmigaOS has the basics and it's extensible. That's better than being stuck with whatever bloat is thrown into Windows.

AOS is primitive? To modern standards, perhaps. But AOS is flexible and simple. To me it seems to offer enough to do all desktop tasks on top of it, we mainly need the SW on top (and to ease up the SW development we need some things to OS).

Yep. Simple and extensible.

 Unless AOS is totally being broken by it's implementators, I doubt it will ever be as sluggish as the mainstream. (not even memory protection should break responsiveness, it has been demonstrated by RTOSs)

I think partial memory protection could be implemented (with MMU) and not affect responsiveness. I'm talking about protecting code and read only data but NOT copying messages. A full sandbox would likely impact the responsiveness.

[matthey]

Actually, ARM has definate advantages in the area.
Its very low power.
X86 isn't quite there yet.
And the 68K never was a low power device.
 
So, arguing the code density issue from that point makes little sense.

ARM has a simple decoder and consumes very little electricity but the integer CPU could be more powerful. x86 is more powerful but has a very complex decoder wasting electricity. The 68k would fit in between with a moderately complex decoder but is similar in integer performance, if not better than x86 (assuming basic enhancements like in 68kF and no 64 bit for low power target). While consuming more electricity than ARM, the 68k has the best code density which helps performance and allows for a smaller memory footprint. The 68060 was pretty low power consumption for it's performance and time.

I have rated the 4 most common processors according to what I think is important for a modern integer CPU. The asterisks are stars with 5 asterisks being the best:

1) electrical consumption/decoder and pipeline simplicity
2) powerful integer instructions and addressing modes
3) conditional and branch hazard performance
4) code density
5) ease of use

68kF in a modernized 68060 like implementation
1) ***
2) *****
3) ***
4) *****
5) ****

ARM with Thumbs
1) *****
2) ***
3) ***
4) ****
5) ***

x86
1) *
2) ****
3) **
4) ****
5) *

PPC
1) ****
2) *****
3) ****
4) *
5) **

Agree or disagree with these ratings? Of course the x86 is a pig made to fly with plenty of money.

[matthey]

I'm just saying that you're falling into the old-OS vs new-OS fanboy behaviour. You cannot compare the two, they're both OS's but from 30 years apart that do completely different jobs.

I like what works well. AmigaOS does and Windows does not.

There are things to be said for the simplicity of AmigaOS but if you like that sort of thing then you should look at HaikuOS and see how to achieve it's minimal feature set still requires some serious CPU performance before you start running any programs on it.

Haiku looks pretty kool from the videos I've seen. I might give it a try if support other than x86 gets better. Otherwise, AROS is getting better .

I think you're on the right track if you take something like the TG68 fpga design and start to do things like improve it to make instructions run in a single cycle, add a 2nd ALU, improve the cache performance ad infinitum.

It would be better to start with the N68050 if Jens ever releases it like he's been talking .

[matthey]

As I understand it the 68K was running into difficulties when it was getting to things like the 68060.  That was one of the reasons they abandoned it.

B.S. This was just anti-marketing the 68060 because Motorola decided they were going the PPC route. The 68060 was outperforming the early PPC processors. Apple made their OS incompatible with the 68060 so it wouldn't be the fastest Macintosh available. In the meantime, Intel was having no problems upping the performance of their x86 line which is more difficult to enhance than the 68k family.

Having a complex and powerful ISA might be wonderful from the programmer point of view but it's most likely the opposite from the hardware designer's point of view.  Someone has to implement all those commands in hardware and this can lead to some very tricky situations.

Many times you are correct but the 68kF was created with performance considerations like:

1) Address registers only allow full 32 bit register updates.
4) Most new instructions update full 32 bit register.
2) SELcc and SBcc were added instead of MOVcc.
3) Smaller 32 bit immediates are compressed (using sign extend instead of shift).
4) Bitfield instructions are retained as they can be fast and update the whole register.
5) Trashing registers is avoided where possible in many different ways.
6) Better orthogonality, address registers allowed more, less register shuffling needed.
7) Many new instructions have a stealth 3 op format without requiring more units.

It is helpful to know a little bit about how a processor works before creating an ISA .

e.g.  What happens if your processor is doing some complex operation and an interrupt comes in?  Do you hold the interrupt and keep going?  What if the operation takes a long time involves reading from RAM?  You probably can't wait that long so you have to find a way of halting the processor, storing the state mid instruction, handling the interrupt, recovering the state and restarting where you left off.

It's more complex but it's already handled well in the 68060. The 68040 was kind of a mess though. There are more complex problems addressed all the time in modern processors than this. Take branch hazards for instance.

Thats the sort of problem the hardware designers have to deal with.  Then you have to build it and test it, including that particular behaviour.  There's a reason no one but IBM and Intel use CISC these days - and they both tried to get rid of it.

Freescale with the ColdFire?