ARM or x86 with FPGA emulator

[TeamBlackFox]

Biggun,

You're not correct at all, because the majority of designs that are getting notice besides RISC are VLIW and EDGE. In VLIW's case it is like super-RISC and even adopts some CISCy advantages.  VLIW is register-register/load-store architecture and basically just adds instruction level parallelism.

EDGE is another way to add instruction parallism by adding one advantage CISC genuinely has: variable length instruction words.

Anyways no, RISC is going to always be simpler and more efficient for most forms of computing. Even x86 cores nowadays break instructions down into simpler ones before processing them.

Of course, biggun you can always try proving me wrong by building this super orthogonal CPU and trying to benchmark it against a processor of the same application that is RISC. I'll be waiting.

[TeamBlackFox]

In addition PSXPhill,

The R16000A is not at 200MHz, it starts at 500MHz and goes all the way to 1GHz. This article was comparing the 1GHz version to some AMD Phenom, I don't know AMD nomenclature so I'm not going to try looking the exact model up.

[bloodline]

You're not correct at all, because the majority of designs that are getting notice besides RISC are VLIW and EDGE. In VLIW's case it is like super-RISC and even adopts some CISCy advantages.  VLIW is register-register/load-store architecture and basically just adds instruction level parallelism.

EDGE is another way to add instruction parallism by adding one advantage CISC genuinely has: variable length instruction words.

Anyways no, RISC is going to always be simpler and more efficient for most forms of computing. Even x86 cores nowadays break instructions down into simpler ones before processing them.

Of course, biggun you can always try proving me wrong by building this super orthogonal CPU and trying to benchmark it against a processor of the same application that is RISC. I'll be waiting.

You haven't studied the ARMv8 yet have you? It's not RISC or CISC or any other marketing term you can think of, it's a weird hybrid of ideas.

[psxphill]

This article was comparing the 1GHz version to some AMD Phenom, I don't know AMD nomenclature so I'm not going to try looking the exact model up.

Ok so I got the MIPS speed wrong, it doesn't change that the metric you've provided is meaningless on it's own (and it highlights that you didn't provide enough information about what cpu & ram speeds were in use and what other chipset etc). You could easily produce a CPU that has an average of 1 cycle for each ram access, just clock the CPU at 1mhz and use 1mhz ram.

Where is the article? It shouldn't take you too long to find out the speed.

http://en.wikipedia.org/wiki/List_of_AMD_Phenom_microprocessors#.22Agena.22_.28B2.2FB3.2C_65_nm.2C_Quad-core.29

I personally wouldn't have bought an AMD chip when the Phenom was out, the Intel core 2 was much better.

[matthey]

You're not correct at all, because the majority of designs that are getting notice besides RISC are VLIW and EDGE. In VLIW's case it is like super-RISC and even adopts some CISCy advantages.  VLIW is register-register/load-store architecture and basically just adds instruction level parallelism.

EDGE is another way to add instruction parallism by adding one advantage CISC genuinely has: variable length instruction words.

Anyways no, RISC is going to always be simpler and more efficient for most forms of computing. Even x86 cores nowadays break instructions down into simpler ones before processing them.

SIMD has generally been favored over VLIW for parallel operations because it doesn't have the major drawbacks of VLIW. VLIW has strong advantages also but it is not practical for general purpose computing despite huge expensive attempts which failed.

RISC is simpler and cheaper to make if you want a low end ARM processor. That short pipeline is going to have bubbles, the instructions are going to be weak and the additional instructions that need to be executed at a higher clock speed have more dependencies than CISC as well as the disadvantages of a higher clock speed. Lengthening the pipeline and/or adding OoO to make the RISC stronger gives the advantages of CISC except the register memory architecture and variable length instructions which give good code density and the decoding can be hidden in the pipeline. RISC has the advantage that more registers can be encoded (needed to avoid dependencies and bubbles) and fewer cache/memory accesses. RISC compilers were supposed to be able to avoid enough bubbles and dependencies that they would outperform CISC in cache/memory but this never came about, even with double the registers. Compilers were supposed to make VLIW practical for general purpose computing but they also failed. There continue to be people that keep repeating the same mistakes though.

Of course, biggun you can always try proving me wrong by building this super orthogonal CPU and trying to benchmark it against a processor of the same application that is RISC. I'll be waiting.

http://www.apollo-core.com/index.htm?page=performance

You haven't studied the ARMv8 yet have you? It's not RISC or CISC or any other marketing term you can think of, it's a weird hybrid of ideas.

It's clearly RISC just not very Reduced Instruction Set much like PPC. RISC should have been called LSAC Load/Store Architecture Computer. There are a lot of conditional instructions and we will see how that works out. It's an advantage on some hardware implementations while no gain on others. They may have gone overboard with this to keep original ARM fans happy while removing the conditional instruction field to add more registers. This change should improve performance to be close to, if not a little better than PPC for integer performance. IMO, ARMv8 should have good performance but it is more complex than it needs to be. This extra complexity could cost them in electrical efficiency and it's not clear that compilers will be able to take advantage. Processor designers have a tendency to add features they visualize as advantages in a hardware implementation they like and often ignore what compilers actually use and need. Then all those instructions that most compilers don't use are dropped and trapped turning the ISA into a mess of pitfalls.

[Linde]

Maybe I'm not understanding your question, because I've been trying to answer it.

I never asked you any question. That could explain your struggle.

I prefer working with an architecture at a low level.

So do I. I say this as a fanatic vim user and shrugging towards the use of IDEs, my point being that vim or make don't somehow expose the hardware architecture in any more obvious way than an IDE like Visual Studio or what-have-you. Make sure exposes some higher level concepts of the build process, and vim is an excellent editor, but they say nothing about the hardware you're working with.

Nothing about the tools I use exposes anything

= my point. Thanks.

I treat C as more flexible assembler.

Surely you can't be saying that C is somehow more flexible than an assembler for any given platform? You know, what with an assembler normally supporting all the possible operations of the CPU, and C leaving you at the mercy of the compiler to decide what is a decent sequence of operations to represent your code.

Mind you, I'm not saying that a good C compiler will make bad choices in terms of optimizations. It will probably do an excellent job turning what is essentially more readable than assembler source into something that is sometimes faster and leaner than what would intuitively seem like the right way in an assembler. You can't really say that it is more flexible, though, in any other sense than that your code might compile for another architecture. It's very detached from the concept of assemblers, really.

[biggun]

Of course, biggun you can always try proving me wrong by building this super orthogonal CPU and trying to benchmark it against a processor of the same application that is RISC. I'll be waiting.

Been there done that ...

http://www.apollo-core.com/

[Linde]

I've been over this: Certified UNIX is different from UNIX in the descendant sense.

Yes, but "the descendant sense" isn't the kind of genealogy that the single UNIX specification treats as a qualifier. Certified UNIX is UNIX. UNIX in "the descendant sense" is some ridiculous qualifier you came up with yourself to avoid encountering any true scotsmen.