Neat coding style and good habits

[roondar]

Originally Posted by demolition

The new ARM 64-bit platform that is coming out is nothing like the ARM performance we are used to. It is very promising and performance-wise much better than the predecessors so it can't be compared. I have heard from many places that unless Intel comes up with something significant very soon, they will lose a major part of the server market very rapidly.

The problem here with the consumer PC market is that people want to be able to run x86 code and because of that it is hard to move them to any other platform. Even if ARM's new 64 bit platform was 50% better than x86, it would still be uphill due to the lacking compatibility.

I do wonder if they can actually keep up the low-power use/high efficiency if they start increasing performance. As I understand it one of the reasons for the ARM's low power use was historically due the relatively 'old-school' design used compared to the Intel chips, which meant they needed less transistors (no deep pipelines or branch prediction for instance - though that may have changed by now).

Since transistor count is pretty much the deciding factor of heat production/energy use (given equal transistor size) it will be interesting to see how this ends up.

[meynaf]

Originally Posted by demolition

The new ARM 64-bit platform that is coming out is nothing like the ARM performance we are used to. It is very promising and performance-wise much better than the predecessors so it can't be compared. I have heard from many places that unless Intel comes up with something significant very soon, they will lose a major part of the server market very rapidly.

I heard the power consumption is gonna raise as well...

[matthey]

Originally Posted by Thorham

Unless you become extremely rich, 68k is never going to go anywhere.

Are you saying I'm the only one with the vision necessary to revolutionize the 68k and make it competitive again? Thanks .

Originally Posted by Thorham

As for FPGA computers: If you can do anything you want, why not try something completely new? If you want to move ahead, then you have to let Amiga go, it's just that simple.

Many people would say the same thing about letting the 68k go as the Amiga. They were good in their day and need modernizing but I still see potential in both. Starting over means losing a user base and support for what is existing. The current road blocking ownership doesn't help but then they will be only minor hurdles when I'm extremely rich.

Originally Posted by meynaf

Compiler designers will care only when we have a significant market share. Else they won't, regardless of how 'nice' the cpu is.
And we won't get there without a good Ghz implementation, which isn't gonna happen.

I don't know if GHz speed is necessary but large production numbers of processors of a single ISA are necessary. We can see that <10k units is not enough with the PPC Amiga guys who have to provide their own compiler support. Anything new would probably want to aim for at least 50k units.

Originally Posted by demolition

The new ARM 64-bit platform that is coming out is nothing like the ARM performance we are used to. It is very promising and performance-wise much better than the predecessors so it can't be compared. I have heard from many places that unless Intel comes up with something significant very soon, they will lose a major part of the server market very rapidly.

The new ARMv8/AArch64 architecture is completely new and radically different than Thumb 2 which put ARM in so many small electronic devices. Thumb 2 is energy efficient but has weak single core performance (the 68k has better single core performance and code density). ARM could not compete in performance with their Thumb 2 so they created a new architecture which most resembles PPC (PPC has better performance and code density than most RISC). The new ARMv8 designs are more powerful but they jumped from a small design to a much larger design (much more logic). Like Intel's Atom which is not the most power efficient, the race is on to win enough market share for the economies of scale necessary to shrink the dies back to good power efficiency. Intel has better die shrinking technology, mature compiler support and is a less than efficient but powerful CISC vs ARM with major market share in embedded, good power efficiency technology and a powerful but less power efficient RISC architecture. There is still a big jump between small and power efficient and large and powerful architectures with room in the middle (where a 68k like CPU is strong) but marketing, hype and support are just as important as any architecture advantages or disadvantages.

[demolition]

So instead of just doing a CPU, would it be realistic to consider a new microcontroller design based on the 68000 instruction set, basically a 68k core with timers, UARTs etc. integrated? The 68k was used in many industrial applications already and is also designed to be a good target for C compilers. So it seems to me like a neat idea to have one IC which combines the CPU with one or more CIA chips. Or does this already exist perhaps?

[Mrs Beanbag]

Originally Posted by meynaf

That may be true, however performance doesn't scale linearly with the number of cpus. I'd like to see real numbers.

On the desktop it certainly doesn't since so many apps and games still only utilise one core, it's getting better now but 8 cores is quite difficult for a single running program to use effectively. On a server it is an entirely different story, and many slow cores can easily outperform a few really fast cores when thousands of threads are running simultaneously. If they really want to break into the server market i reckon they should be going the route of the UltraSparc T1 - dispense with all the complex circuitry like out-of-order execution, register renaming &c and use maximum hyperthreading instead.

Yet if you benchmark the average x86 vs the average arm, the arm is everything but impressive. I don't want that in my laptop.

Maybe it's not right for you, but i generally only build systems with low-end AMD chips to run Linux so it's not putting me off. It will be a long time before we see an ARM chip in a high-end gaming rig, but i see no technical reason why not, in the long term. Maybe business reasons, but not technical ones.

[meynaf]

Originally Posted by Mrs Beanbag

Maybe it's not right for you, but i generally only build systems with low-end AMD chips to run Linux so it's not putting me off. It will be a long time before we see an ARM chip in a high-end gaming rig, but i see no technical reason why not, in the long term. Maybe business reasons, but not technical ones.

There is a very simple technical reason why the ARM can't be in the high-end gaming. It can't compete because it needs more instructions to perform the same job. As easy as that.

[Mrs Beanbag]

Originally Posted by meynaf

There is a very simple technical reason why the ARM can't be in the high-end gaming. It can't compete because it needs more instructions to perform the same job. As easy as that.

this seems to miss the entire point of RISC philosophy, that the less common x86 instructions that require multiple ARM instructions are outweighed by the common, simple instructions that can be decoded that much quicker, resulting in shorter pipelines, lower latencies &c and a saving in cycles overall. So it is really not as easy as that at all.

Plus so much of the hard work is increasingly being farmed off to the GPU now anyway.

[meynaf]

Originally Posted by Mrs Beanbag

this seems to miss the entire point of RISC philosophy, that the less common x86 instructions that require multiple ARM instructions are outweighed by the common, simple instructions that can be decoded that much quicker, resulting in shorter pipelines, lower latencies &c and a saving in cycles overall. So it is really not as easy as that at all.

The RISC philosophy failed because now logic gates count is no longer a big deal. So ARM won't decode faster than x86, it just uses less logic to do so.

Originally Posted by Mrs Beanbag

Plus so much of the hard work is increasingly being farmed off to the GPU now anyway.

Yea but this doesn't mean the cpu is no longer important.

[Mrs Beanbag]

Originally Posted by meynaf

The RISC philosophy failed because now logic gates count is no longer a big deal. So ARM won't decode faster than x86, it just uses less logic to do so.

It still means shorter pipelines = less branch penalty, x86 has ways around this obviously, and Intel may eat transistors for breakfast but that doesn't mean there aren't better uses for them. How many cores can you fit on a die? How much cache do you want? They're putting GPUs on die now as well, the possibilities are endless.

Yea but this doesn't mean the cpu is no longer important.

True, anyway i think ARM is going to aim for the server market before it produces anything useful to gamers.

[meynaf]

Originally Posted by Mrs Beanbag

It still means shorter pipelines = less branch penalty, x86 has ways around this obviously, and Intel may eat transistors for breakfast but that doesn't mean there aren't better uses for them. How many cores can you fit on a die? How much cache do you want? They're putting GPUs on die now as well, the possibilities are endless.

The difference is too small to account for anything significant. Most of what's on the die today really is cache memory.
Most of the rest is eaten by fpu, vector cores, or whatever.

Originally Posted by Mrs Beanbag

True, anyway i think ARM is going to aim for the server market before it produces anything useful to gamers.

It won't be easy. What's the current ARM market share in this segment ? 1% maybe ?

[Mrs Beanbag]

ok no point arguing this anymore, it's way off topic anyway

[matthey]

Originally Posted by demolition

So instead of just doing a CPU, would it be realistic to consider a new microcontroller design based on the 68000 instruction set, basically a 68k core with timers, UARTs etc. integrated? The 68k was used in many industrial applications already and is also designed to be a good target for C compilers. So it seems to me like a neat idea to have one IC which combines the CPU with one or more CIA chips. Or does this already exist perhaps?

Every 68k CPU with Amiga chip set in a single FPGA chip is practically a simple SoC (FPGA Arcade, Mist, Vampire). A microcontroller usually refers to a lower end CPU but today often has primitive SoC like capabilities. The stripped down ColdFire is used in some microcontrollers. Motorola/Freescale offered 68000 and CPU32 microcontrollers like the 683xx/DragonBall. There is the FIDO microcontroller (CPU32 ISA) which is probably the most powerful hard 68k SoC today.

http://www.innovasic.com/products/fi...ion-controller

FIDO and the DragonBall are advanced and powerful enough to be in the SoC realm. DragonBall was used in the Palm devices where it was easy to use but Motorola/Freescale did not continue to upgrade it and gave up the market to ARM. The 68060 shows the 68k can have good performance at a reasonable power efficiency but Motorola has always backed away from powerful 68k designs maybe because it threatened the PPC domain (a 68060 Mac laptop would have outperformed low end PPC back in the day). The FIDO is really a purpose built microcontroller for industrial robotics which needs low latency ethernet although the FIDO is flexible enough to be sold for other embedded uses. It basically has a primitive OS in hardware which is very innovative and has advantages for security and reduced latency but creates a challenge for integrating in other OSs and using with compiled code. Dave Alsup is the system architect of FIDO and the guy I talked to at Innovasic about the Apollo core. They showed interest and were very nice but the Apollo core was untested and the AmigaOS is a big loose end. Companies want to avoid risk after the Great Recession so anything new is a tough sale.

Originally Posted by Mrs Beanbag

On the desktop it certainly doesn't since so many apps and games still only utilise one core, it's getting better now but 8 cores is quite difficult for a single running program to use effectively. On a server it is an entirely different story, and many slow cores can easily outperform a few really fast cores when thousands of threads are running simultaneously. If they really want to break into the server market i reckon they should be going the route of the UltraSparc T1 - dispense with all the complex circuitry like out-of-order execution, register renaming &c and use maximum hyperthreading instead.

More cores or multi-threading is more difficult to program. Games often need strong single core performance as well. This is why there aren't more games on the Raspberry Pi for example. Recompiling decades old x86 games often results in poor performance. The single core performance of the Pi 2 is about the same as a Pentium III if RISC bottlenecks can be avoided.

Originally Posted by meynaf

There is a very simple technical reason why the ARM can't be in the high-end gaming. It can't compete because it needs more instructions to perform the same job. As easy as that.

I don't think it is quite as simple as that. Parallel performance is a big factor to consider. There were many fallacies from RISC marketing back in the day though.

Fallacy: RISC was supposed to clock higher due to simplicity.
Truth: Clocking up a CPU is usually not the most efficient way to increase performance.

Fallacy: RISC was supposed to move complexity out of the CPU and into compilers.
Truth: Compilers can't assume anything so many optimizations aren't possible.

Fallacy: RISC was supposed to do more in parallel as it is simpler.
Truth: RISC can't fetch enough big instructions to execute more than a few instructions in parallel.

Fallacy: RISC simplifies load/store operations saving logic.
Truth: RISC generates bubbles after load operations and needs bigger caches for more instructions making it slower and taking more logic for caches and rescheduling bubbles with OoO.

Fallacy: RISC was supposed to simplified decoding removing a bottleneck.
Truth: A variable length encoding acts like code compression which saves caches and memory with no slow down during decoding.

RISC still seems to be the favored CPU design, I guess because they are easier and cheaper to make, despite all the RISC architecture failures. What businesses are working on new CISC designs despite the success of the performance king of CPUs for 2 plus decades and the mediocre CISC design of x86_64? Even the CISC 68k didn't die but was abandoned for greener pastures which weren't so green with PPC.

[Mrs Beanbag]

yeah abandoning 68k for PPC was a mistake, easier to see in retrospect. 68k seems the perfect halfway house between RISC and x86.

[NorthWay]

I like RISC. I kinda see it as
- 8bit is 1 operand (2nd and 3rd implied)
- 16bit (68K/x86) is 2 operand (and 3rd implied)
- RISC is 3 operand
and they all use logic circuits with 2 inputs and 1 output.

But if we are offtopicing then I really really (really) like what I see from Mill Computing - it should be an excellent match for an Exec MK II OS/kernel or at least some mainstream microkernel.

[Mrs Beanbag]

x86 was originally 8 bit*... 68k was internally 32 bit from the beginning, only external data bus was 16 bit.

*EDIT sorry not quite true, 8086 was 16 bit but there was 8088 which was a version with 8 bit data bus (and was used in the original "PC")

[Thorham]

Originally Posted by Mrs Beanbag

x86 was originally 8 bit*... 68k was internally 32 bit from the beginning, only external data bus was 16 bit.

The 68000 has a 16bit ALU.

[Samurai_Crow]

Originally Posted by NorthWay

I like RISC. I kinda see it as
- 8bit is 1 operand (2nd and 3rd implied)
- 16bit (68K/x86) is 2 operand (and 3rd implied)
- RISC is 3 operand
and they all use logic circuits with 2 inputs and 1 output.

But if we are offtopicing then I really really (really) like what I see from Mill Computing - it should be an excellent match for an Exec MK II OS/kernel or at least some mainstream microkernel.

Modern x86 and the Apollo 68080 support a third operand as well, the former using a prefix, the latter using opcode fusion of a dummy move instruction.

[idrougge]

Originally Posted by Thorham

The 68000 has a 16bit ALU.

The Z80 has a 4-bit ALU.

[meynaf]

Originally Posted by NorthWay

I like RISC. I kinda see it as
- 8bit is 1 operand (2nd and 3rd implied)
- 16bit (68K/x86) is 2 operand (and 3rd implied)
- RISC is 3 operand
and they all use logic circuits with 2 inputs and 1 output.

But if we are offtopicing then I really really (really) like what I see from Mill Computing - it should be an excellent match for an Exec MK II OS/kernel or at least some mainstream microkernel.

I don't like RISC at all. It's a pain to code in ASM. From day one i saw the transition to PPC as a bad move - but nobody listened to me.

Originally Posted by Mrs Beanbag

x86 was originally 8 bit*... 68k was internally 32 bit from the beginning, only external data bus was 16 bit.

*EDIT sorry not quite true, 8086 was 16 bit but there was 8088 which was a version with 8 bit data bus (and was used in the original "PC")

The 8088/8086 derive from the 8080, which is really 8-bit.
Internally the 68000 is playing 32-bit with 16-bit components. You can consider it's 16. You can consider it's 32. Depends where you look.

Originally Posted by Thorham

The 68000 has a 16bit ALU.

True, but it has a 32-bit instruction set.

Originally Posted by idrougge

The Z80 has a 4-bit ALU.

Isn't it 8-bit instead ?

[Megol]

Originally Posted by matthey

Most modern processors include instructions like the ColdFire MVS, MVZ and BYTEREV for example. These operations were less common when the 68k was new but are common and practically expected today. Later 68k processors removed the integer 64 bit result MULS.L/MULU.L, several fp instructions, etc. which even later processors like ARM and x86_64 added.

IMHO MVS/MVZ aren't important enough to occupy the large opcode space like in Coldfire, a more limited version would be enough. I'd also prefer a MOVLE.B/W/L instruction instead of BYTEREV.

The 80386 supported 32*32->64 and 64/32->32:32 (quotient/remainder), AMD64 supports 64*64->128 and 128/64->64:64 (q/r).

The 68k needs too many branches because of lack of a few instructions like shift with immediates >8 although fast bit field instructions, predication, etc. can help this.

That's one of the warts of the 68k ISA :/ IIRC there are enough space to encode shifts with an extended immediate field with some limitations.