ARM or x86 with FPGA emulator

[TeamBlackFox]

Actually Fiz I do know what I'm talking about.

I think AmigaOS 4's best chance of survival is not emulation or on x86, but on an open design based on the NUMA architecture ( Basically it is a decentralised DMA system which is widely copied, Intel uses QPI which takes a lot of the same ideas ) and I fully support breaking both API and ABI as well as architectural compatibility for a sustainable architecture. Both MIPS and SPARC have open designs, which means A-EON could improve them without a license.

The primary advantages of AmigaOS are that it is lightweight without being impractical, and that has nothing to do with its backwards compatibility. Instead, make the OS fully 64-bit and use FS-UAE as an integrated sandbox for old software, add a ports system like in BSD as well as a frontend to it, which will make software dependency and distribution easy, NUMA architecture would increase bus performance and make a CPU that isnt as fast be less of a hindrance. CPU frequency is pretty much BS when a 1GHZ R16000A MIPS CPU wipes the floor with a 3GHz Pentium 4, all higher frequency does is make more heat and power consumption.

The only reason I don't support ARM is that up until recently most designs have been 32-bit, which in today's world of cheap memory doesn't make sense. In addition most ARM CPUs are for mobile and embedded devices. I have a Nexus 7 tablet, I love it, but it isn't any better than my 600MHz Octane2 at computational tasks, however in memory access and graphics, there is no contest, but that is to be expected.

[biggun]

Both MIPS and SPARC have open designs, which means A-EON could improve them without a license.

Are you aware of "OPEN POWER"?

[WolfToTheMoon]

http://riscv.org/

http://www.lowrisc.org/

  lowRISC is producing fully open hardware systems. From the processor core   to the development board, our goal is to create a completely open computing   eco-system.  
      Our open-source SoC (System-on-a-Chip)   designs will be based on the 64-bit RISC-V instruction   set architecture. Volume silicon manufacture is planned   as is a low-cost development board

[TeamBlackFox]

Are you aware of "OPEN POWER"?

Yes, but as far as I know there are differences between the parent POWER architecture and the PowerPC architecture, no? In addition, I'd think the cost to produce a MIPS or SPARC processor would be less.

If someone can build a NUMA/DDR3/PowerPC board and AmigaOS 4 is fully 64-bit on it, I'd be willing to pick it up at a price point of $1200 or so. I'd pay more if they donated boxes to the BSD projects though.

Currently the X1000 I would not pay over $600 for considering its specifications. Not to insult anyone but I can get a used HP C9000 PA-RISC for $300 that is as fast as a G5 but has SCSI on it ( I prefer SCSI for build quality )

[OlafS3]

Yes, but as far as I know there are differences between the parent POWER architecture and the PowerPC architecture, no? In addition, I'd think the cost to produce a MIPS or SPARC processor would be less.

If someone can build a NUMA/DDR3/PowerPC board and AmigaOS 4 is fully 64-bit on it, I'd be willing to pick it up at a price point of $1200 or so. I'd pay more if they donated boxes to the BSD projects though.

Currently the X1000 I would not pay over $600 for considering its specifications. Not to insult anyone but I can get a used HP C9000 PA-RISC for $300 that is as fast as a G5 but has SCSI on it ( I prefer SCSI for build quality )

not to insult you but whom do you want to sell it. It is even more obscure than PPC today, I would even say PPC is almost mainstream compared to MIPS or SPARC and hardware nobody knows is more difficult to sell exept you would have a kind of "killer application" where the hardware is not important. And what would be the advantage dropping some of the advantages of PPC like the 68k integration and change from one obscure to a even much more obscure platform. Then why not using ARM or X86/X64?

[TeamBlackFox]

No offense taken! I realise my opinion may not be the norm at all.

PowerPC is not very common in the consumer market, same goes for SPARC, MIPS et cetera. However in the server market SPARC and POWER, the parent architecture of PowerPC are both well known. MIPS is currently embedded but has server grade and consumer grade designs available such as R10000 and derivatives.

The reasons I'm opposed to moving to x86 are simple: It is a pedantic, relic architecture which uses dirty hacks and workarounds to overcome the design limits of the original 8086, which by all accounts is a terrible processor. x86 is very orthogonal compared to all but a few mainframe architectures in common use today, but beyond that I've ran servers for 3-4 years and in that time my x86 boxes have died catastrophically, one caught fire and destroyed two XServe in the same cage. The build quality is just atrocious and delicate. I run computers hard and for a long time at high load ( I have computers I loan out for remote access and compiling ) and I've had no RISC system fail because of that. Therefore x86 ends up costing a consumer a lot more in time and money as one has to continuously replace broken hardware. Not the case for my RISC boxes.

I'm not opposed to a high performance, 64-bit ARM design at all, but those do not seem to exist. 32-bit is an engineering dead end, 4GB RAM just doesn't cut it. Need I remind anyone about the Y2038 bug that will render most old UNIX and similar systems inoperable? 64-bit is the future, even at the cost of compatibility.

Current offerings from ACube and AEON are overpriced and underpowered, so why not move to an open architecture and mature the operating system at the same time. MIPS is being widely produced in China and Japan which means low production costs, SPARC has open designs as currently stated as well. The PA6T chip is pretty much a dead end, newer POWER ISA chips are expensive as hell so I don't see a future here.

[OlafS3]

No offense taken! I realise my opinion may not be the norm at all.

PowerPC is not very common in the consumer market, same goes for SPARC, MIPS et cetera. However in the server market SPARC and POWER, the parent architecture of PowerPC are both well known. MIPS is currently embedded but has server grade and consumer grade designs available such as R10000 and derivatives.

The reasons I'm opposed to moving to x86 are simple: It is a pedantic, relic architecture which uses dirty hacks and workarounds to overcome the design limits of the original 8086, which by all accounts is a terrible processor. x86 is very orthogonal compared to all but a few mainframe architectures in common use today, but beyond that I've ran servers for 3-4 years and in that time my x86 boxes have died catastrophically, one caught fire and destroyed two XServe in the same cage. The build quality is just atrocious and delicate. I run computers hard and for a long time at high load ( I have computers I loan out for remote access and compiling ) and I've had no RISC system fail because of that. Therefore x86 ends up costing a consumer a lot more in time and money as one has to continuously replace broken hardware. Not the case for my RISC boxes.

I'm not opposed to a high performance, 64-bit ARM design at all, but those do not seem to exist. 32-bit is an engineering dead end, 4GB RAM just doesn't cut it. Need I remind anyone about the Y2038 bug that will render most old UNIX and similar systems inoperable? 64-bit is the future, even at the cost of compatibility.

Current offerings from ACube and AEON are overpriced and underpowered, so why not move to an open architecture and mature the operating system at the same time. MIPS is being widely produced in China and Japan which means low production costs, SPARC has open designs as currently stated as well. The PA6T chip is pretty much a dead end, newer POWER ISA chips are expensive as hell so I don't see a future here.

You already wrote that some X86 caught fire, I personal never experienced that and not heard from anyone else but it might be that this can happen when a device has heavy load over long time but it also depends on what parts you use for that.

Regarding dirty hacks and not a clean architecture might be true but for almost anyone that is more or less a academic question. The application developer use tools with modern compilers that hide all that. I for example develop with Visual Studio and Delphi on Windows, I do not care over architecture there. And the user even cares less

if you want to offer it people know Intel (or AMD), they even know ARM if you say it is also used in Smartphones but only few know SPARC or MIPS. And if you say it runs 10 years without problem, that is fine but people replace their hardware every couple of years so a PC running 10 years is not needed. You can regret that but try to sell people a five or eight years old system. Mission impossible :-) No if they would ever make a ISA change (what I do not believe for a number of reasons) they should take something "mainstream" and not something exotic again.

[TeamBlackFox]

Therein lies our differences in development style:

I mostly use Vi and Vim as a text editor, and use simple makefiles ( I want to find a simpler build system though ) with compilers like MIPSPro, PCC and Clang. I don't dare touch Windows development because I just can't take it. In addition IDEs are useless to me because they breed laziness. I also don't use C++ as I think it doesn't keep code concise and optimised.

I don't like the fact that even Intel or Microsoft compilers produce crap code, and again I like compilers to be smart and optimise code as much as possible. The day Amiga goes mainstream as it stands is the day it goes the way of BeOS. Haiku I've lost hope for as well because binary compatibility with the outdated ABI of BeOS has slowed them down.  You're free to take that as bull, but think about it: All successful in terms of numbers OSes are supported and dominated by a company who restricts the software's openness. Apple and Microsoft already do this, and Canonical and RedHat have already dominated GNU/Linux and used the GPL to lock software to GNU/Linux in an attempt to strangle the BSDs, which are supported but not dominated by software companies. And honestly RedHat keeps adding useless software to GNU/Linux to Windowsify it and make it "easier". They can't admit that BSD has the leg up on stability and so they're strangling it and the rest of the open market by adding dependency for PulseAudio, systemd, policy it etc.

The only way to break the cycle is to keep your projects in the niche where you aren't risking money in a gamble to beat the big dogs. It amazes me how arrogant most people on here are in this effect.

[Linde]

Therein lies our differences in development style:

I mostly use Vi and Vim as a text editor, and use simple makefiles ( I want to find a simpler build system though ) with compilers like MIPSPro, PCC and Clang. I don't dare touch Windows development because I just can't take it. In addition IDEs are useless to me because they breed laziness. I also don't use C++ as I think it doesn't keep code concise and optimised.

Your development style perfectly proves his point, which seems to have gone by unnoticed:

The application developer use tools with modern compilers that hide all that.

Whatever you think of make, vim or whichever C compiler you prefer, you can't really argue against his point on their basis.

[Kremlar]

but beyond that I've ran servers for 3-4 years and in that time my x86 boxes have died catastrophically, one caught fire and destroyed two XServe in the same cage.

As others have pointed out, that really sounds quite bizarre.  What brand/model servers were these?  And you somehow equate a system supposedly catching fire to the type of processor it has?

[Terminills]

What is it you think Moore's law has to do with netburst exactly? Moore's law is based on performance, not clock rates. Additionally x86 has been risc like for many years. The multiple micro ops idea has been in practice for about a decade. Also, contrary to what you've suggested clock rates are becoming a focus again (not soley, but equally to core count). Devil's Canyon modifications support this, as does the fact you can buy x86 cpus whose stock frequencies are 5ghz. Why would A-eon make a board supporting 16* the memory the os its designed for?
No offense intended, but your post reads like something strung together by someone who's trying to sound more informed than they are. More holes than solid.

sigh... Moore's law actually had nothing to do with performance per say.  It was about complexity.

"The complexity for minimum component costs has increased at a rate of roughly a factor of two per year (see graph on next page). Certainly over the short term this rate can be expected to continue, if not to increase. Over the longer term, the rate of increase is a bit more uncertain, although there is no reason to believe it will not remain nearly constant for at least 10 years. That means by 1975, the number of components per integrated circuit for minimum cost will be 65,000."

[TeamBlackFox]

I'm using the same method and tools other people are using so there is no point other than my method is console based and doesn't have a GUI. I'm not using an ancient compiler: the oldest compiler I've used is from 2006 - and it works fine with the C 99 standard. An IDE is just a graphical front end with proprietary or compiler specific libraries which hinder portability... Tell me again how that makes a programme any better?

Processor architecture does make a difference because RISC specific compilers like MIPSPro are designed to directly compile highly optimised code for use on their architecture. There is a reason -O3 is recommended in the documentation of Nekoware, an open source suite of software for SGI MIPS systems running IRIX.

Kremlar,

Its been a while so I don't remember the brand, but it was a dual Xeon server refurbished from the manufacturer. It failed three days after me and one of my friends who shares the cost of server cage space verified it for its 90 day evaluation. Everything was working fine on it. We had scarcely had it two years when the fire occurred. The fact is not that it was x86 that caused the fire, it is the fact we paid for a server grade hardware solution and got cheap rubbish instead. Nobody here I think has run their servers as hard as we did, and we do it because the servers are marketed to take this. Now we run increasingly more MIPS hardware converted for server use. No matter that some of it is 20 years old, our Sun and SGI racks have not had a single failure of a server in the same time that various servers running x86 and x64 hardware have given up the ghost. Luckily most just stop working, but there is a reason our hardware is now segregated by type: makes it easier to contain costly losses. The fact is I can get a few racks of SGI Origins for dirt cheap and when craylinked properly I get all the performance I need out of them and most of the time if there is an issue, it is an easy fix like a fan replacement or a cable reseat.

[Kremlar]

Perhaps there was something very defective about your server.  The fact that it caught on fire and you can't even remember the brand strikes me as odd - I sure as heck would remember the brand of something that caught fire on my property.

Either way you can't damn all servers that use the same processor architecture because you're not buying decent equipment.  I've sold hundreds of servers and never had one catch fire.  We mostly do low/medium-end ($5K - $10K) Intel white label, and we have NEVER had a server catch fire and the systems are incredibly reliable.  Intel provides top notch warranty service as well.

Now, if I spend $35K-$40K on a Power7 I do expect it be a better built server - but that has nothing to do with the processor architecture.

[Linde]

I'm using the same method and tools other people are using so there is no point other than my method is console based and doesn't have a GUI. I'm not using an ancient compiler: the oldest compiler I've used is from 2006 - and it works fine with the C 99 standard. An IDE is just a graphical front end with proprietary or compiler specific libraries which hinder portability... Tell me again how that makes a programme any better?

Why should I tell you that? Have I ever questioned that opinion? The original point (again) seems to have gone by unnoticed. I'll quote it once again, including some more of the context:

Regarding dirty hacks and not a clean architecture might be true but for almost anyone that is more or less a academic question. The application developer use tools with modern compilers that hide all that.

Unless you think that vim or make expose something about the CPU architecture that an IDE wouldn't, I don't see how your argument is at all relevant. You say that your development styles differ, I get that, but I can't really make the connection between that sentiment and the argument you were responding to. I'm growing quite content with the idea that you may just be blathering on without any purpose of taking part of the debate, though.

[Linde]

BTW, we had smoke develop in our server room due to faulty hardware. Turns out a hard disk cable had melted and shorted. It was a regular beige box though, so not exactly server grade hardware, and of the things I can think of that potentially catch fire, the CPU is pretty far down the list.

[OlafS3]

I'm using the same method and tools other people are using so there is no point other than my method is console based and doesn't have a GUI. I'm not using an ancient compiler: the oldest compiler I've used is from 2006 - and it works fine with the C 99 standard. An IDE is just a graphical front end with proprietary or compiler specific libraries which hinder portability... Tell me again how that makes a programme any better?

Processor architecture does make a difference because RISC specific compilers like MIPSPro are designed to directly compile highly optimised code for use on their architecture. There is a reason -O3 is recommended in the documentation of Nekoware, an open source suite of software for SGI MIPS systems running IRIX.

Kremlar,

Its been a while so I don't remember the brand, but it was a dual Xeon server refurbished from the manufacturer. It failed three days after me and one of my friends who shares the cost of server cage space verified it for its 90 day evaluation. Everything was working fine on it. We had scarcely had it two years when the fire occurred. The fact is not that it was x86 that caused the fire, it is the fact we paid for a server grade hardware solution and got cheap rubbish instead. Nobody here I think has run their servers as hard as we did, and we do it because the servers are marketed to take this. Now we run increasingly more MIPS hardware converted for server use. No matter that some of it is 20 years old, our Sun and SGI racks have not had a single failure of a server in the same time that various servers running x86 and x64 hardware have given up the ghost. Luckily most just stop working, but there is a reason our hardware is now segregated by type: makes it easier to contain costly losses. The fact is I can get a few racks of SGI Origins for dirt cheap and when craylinked properly I get all the performance I need out of them and most of the time if there is an issue, it is an easy fix like a fan replacement or a cable reseat.

As I said it is more or less academic to me. I develop and sell a own-developed software + different services to small companies, time is rare and I have to live from my work so I do not want to care about implementation details or (even worse) hardware architecture, I use classes (partly added as components visible and invisible) to add functionality and am happy if I do not need to care about it. For example event management is automatically managed by the environment so for me programming on amiga is a big step back. Most people are now using such tools for development so if we want more programmers and more software we would need such tools but that would be another topic. What I mean here as a application programmer I want to concentrate on my product and not too much on API details and not at all on hardware architecture. And user do not care about OS or hardware at all.

Using something more "mainstream" has other advantages too because you can more easily port components/software. As a example you can add a JIT to OWB because there is a X86 version, I do not think that this exists for SPARC/MIPS. Both are only known to me (by name) as processors for workstations and servers and not for typical end-users so changing to them would mean disadvantages regarding loosing parts of the 68k integration and still have the problems of being exotic. Then I would even say better stay with PowerPC despite the known problems.