Welcome, Guest. Please login or register.

Author Topic: ARM or x86 with FPGA emulator  (Read 21398 times)

Description:

0 Members and 1 Guest are viewing this topic.

Offline matthey

  • Hero Member
  • *****
  • Join Date: Aug 2007
  • Posts: 1294
    • Show all replies
Re: ARM or x86 with FPGA emulator
« Reply #14 from previous page: August 21, 2014, 12:00:18 AM »
Quote from: TeamBlackFox;771333
Matthey, I'll check it out. Thanks. I've been meaning to get a faster CPU, but that will take a while with my money.


Maybe there will be a cheaper big box 68k fpga accelerator sometime next year with 128MB or more of memory, ethernet, etc.

Quote from: TeamBlackFox;771333

And in regards to that tidbit on 32 vs 64-bit overhead, I  find 32-bit unacceptable for a modern computer. While many Amigans may be happy with that: I will not be, because I primarily use BSD. I have no use for AmigaOS as my daily driver. It is a distraction and game machine, nothing more.


There is a place for both small 32 bit "fun" devices which can still do a lot of work and 64 bit power machines for large compiles, big number crunching and servers. Frank Wille programmed the Solid Gold and SQRXZ games for a 68k with less than 1 MB of memory but he also writes code for NetBSD which he uses on the SUN server that is used for the vbcc links above:

http://sun.hasenbraten.de/
http://sun.hasenbraten.de/~frank/projects/

Hmm, another Amiga user with connections to BSD. He does support PPC Amigas also although he doesn't like the attitude of the AmigaOS 4 developers. The AmigaOS 4 developer attitude turns me off even more than the high prices. I love the 68k but PPC would be acceptable for a high end AmigaOS if that was a good choice that was going somewhere.

Quote from: TeamBlackFox;771333

I agree though that ARM may be a decent target, but I'd have to wait one more ISA generation because I'm not interested in portable computers much, I want workstations and servers. I own a Nexus 7 and a LG Optimus F6 but I'd never want that to be running AmigaOS or AROS as they're already buggy enough. Much of the time they just function as portable media players and remote terminals


The AmigaOS 3.1 on is not so buggy although some parts are kludgy. The AmigaOS never got much server software and even the networking support is lacking. It doesn't have the security, memory protection or resource tracking that would be highly desirable for a server. Maybe AROS could be improved to be an acceptable server but BSD will likely always be a better choice for what you are interested in.
 

Offline matthey

  • Hero Member
  • *****
  • Join Date: Aug 2007
  • Posts: 1294
    • Show all replies
Re: ARM or x86 with FPGA emulator
« Reply #15 on: August 22, 2014, 01:24:54 AM »
Quote from: TeamBlackFox;771431
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.

Quote from: TeamBlackFox;771431
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

Quote from: bloodline;771433
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.