Amiga.org
Amiga computer related discussion => General chat about Amiga topics => Topic started by: ElPolloDiabl on May 06, 2014, 07:23:05 AM
-
This might be good as an AROS bounty. Otherwise just a hypothetical.
Has there even been an attempt to use an x86 or ARM as a co-processor for the Amiga?
-
P.S. Someone start a kickstarter to have OS4.1 ported to the much cheaper ARM platform.
-
Hyperion just isn't interested in porting AmigaOS onto a cheap, mass market hardware solution.
AROS on ARM is the best option, with a 68k emulator for native app compatibility (hopefully still calling the native AROS libs, like OS4's Petunia emulator).
An FPGA for native hardware compatibility is a nice thought, but would turn the hardware from cheap commodity into bespoke expensive. So a perfect match for this community.
-
AROS on ARM is the best option, with a 68k emulator for native app compatibility (hopefully still calling the native AROS libs, like OS4's Petunia emulator).
Petunia (OS4) or Trance (in MorphOS) is more of a binary translator/recompiler than it is a emulator/simulator; it basically recompile the 68k bytestream into native PPC code. This makes sense on a big endian HW architecture like PPC, because it makes it possible to mix "68k code" with PPC code in the same environment and run old and new programs (and OS components as well, like ARexx for examples) in the same environment as they were no different to each other. In fact they *aren't* different, both 68k and PPC apps are all de-facto PPC native at runtime, being scheduled by the same scheduler, sharing the same memory and system resources, etc. In this way, both MorphOS and OS4 *is* the native Amiga environment, where both new and old applications runs side by side, but on a different HW platform.
This isn't really possible on a little endian platform though, and AROS has a different approach where UAE is used to emulate a complete Amiga machine (with 68k CPU, custom chips and the whole shebang). The upside of this is an improved compatibility with very old SW and/or HW hitting applications, but the downside (compared to the MorphOS/OS4 approach) is that the Amiga apps runs "sandboxed" inside this emulated Amiga, and the AROS native ARM/x86 apps runs outside this box under AROS.
An FPGA for native hardware compatibility is a nice thought, but would turn the hardware from cheap commodity into bespoke expensive. So a perfect match for this community.
A terrible idea if you ask me. There are mainly two groups of Amiga users today, those who are here for the "classic", who are more of retro fans today, and those who are here for "NG", which is more about evolution than retro. The retro people use real Amigas, or emulators, or "new classic" HW like Minimig.
A product like you are talking about would not suit the retro fans, since they are more interested in "the real deal" and 100% compatibility (and like it or not, new HW compromises backwards compatibility). And the "NG" fans will feel the platform is being held back by 20 year old museum level technology. So it would be stuck in the middle, not really satisfying any of the groups.
IMHO of course! ;)
:)
-
I do not feel "retro" like some of the "NG" fans always insist. For me "68k" is only a compiler target and running in emulation beats many of the so called "NG" options. Aros Vision f.e. inherits the same limitations that all AROS versions have. It is part of a bigger family :-). So for me "68k" is not retro and has the advantage to run almost anywhere.
What are the advantages of NG except faster 3D (if drivers would exist)?
-
I suppose I was talking about the PowerUP cards, but that usually ends up being a fast computer with a slow computer tacked on.
-
I suppose I was talking about the PowerUP cards, but that usually ends up being a fast computer with a slow computer tacked on.
This is the problem.
One could take a nice fast ARM chip, as used in a tablet or smart phone. These things are usually multiple core chips with a gig or so of RAM, and come in at a power budget of of only a couple of watts and don't produce much heat.
This makes them ideal for use in an Amiga accelerator... But they also tend to have a graphics core included (much better than AGA), also they have high def audio outputs, and they have USB as standard now... So why bother making all that effort to mate it up with an Amiga motherboard, the only parts you would probably use are the keyboard and disk drive...
-
Makes me think of http://www.amigahistory.co.uk/inside.html
-
An ARM CPU card for the FPGA Arcade would make an interesting addition to it. It would give you a lot of options. You could configure the system to work as a 68k AGA+ machine with the ARM emulating the 680x0 (assuming it would outperform a softcore) or the ARM could be used as a coprocessor to offload jobs like video, audio, jpeg decoding and provide networking and USB features or you could configure it to work as an AROS on ARM NG Amiga.
If Hyperion had any interest in porting OS4 to anything else they'd have done it by now.
Because MorphOS has also remained shackled to PPC it's not something I've paid much attention to so I don't know how open they would be to porting to another architecture.
-
This makes them ideal for use in an Amiga accelerator... But they also tend to have a graphics core included (much better than AGA), also they have high def audio outputs, and they have USB as standard now... So why bother making all that effort to mate it up with an Amiga motherboard, the only parts you would probably use are the keyboard and disk drive...
I sort of agree, but the phase 5 boards had a graphics card option too.
I quite like the idea of being able to run a 68k & PPC emulator on a fast ARM processor and being able to use either AGA or the accelerators graphics output.
Pure cpu emulators designed to run full speed should be able to run quicker than one designed to emulate AGA etc as well.
I guess you'd boot from AROS for ARM and have it so that could select between booting an ARM workbench, which could run 68k apps in AROS using headless mode (like juae) or startup a 68k task that just booted from a 68k kickstart. Quite what the hard drive of a dual boot system would look like is another matter, ideally if you disable the accelerator it would use the onboard 68000 (A500/A600/A2000), 020 (A1200) or 030 (A3000/A4000CR) and it would still be able to use the onboard 68k kickstart and the 68k workbench from the hard drive. A4000 is the odd one out, there is no onboard CPU.
-
An ARM CPU card for the FPGA Arcade would make an interesting addition to it. It would give you a lot of options. You could configure the system to work as a 68k AGA+ machine with the ARM emulating the 680x0 (assuming it would outperform a softcore) or the ARM could be used as a coprocessor to offload jobs like video, audio, jpeg decoding and provide networking and USB features or you could configure it to work as an AROS on ARM NG Amiga.
The FPGA Arcade has an ARM processor. It is low end so probably wouldn't help with emulation much but it can be used to offload some tasks much as the version of the MiniMig with ARM.
-
Adding x86 or arm to the fpga to emulate 68k/powerpc is a bad idea.
No one will make software for the emulator.
Amiga 68k is not a bad computer, but 68k is too slow.
What we really need is to add powerpc to fpga.
Fast 68k does not exist, the mythical 68k from natami exists only in a sick imagination of gunnar von boehn.
x86 and arm as litte endian processors do not allow for integration with existing software.
SPARC, Itanium, Z * from IBM are too expensive.
MIPS, SH4 are too slow.
PowerPC is the only reasonable solution for the Amiga in an FPGA.
-
Adding x86 or arm to the fpga to emulate 68k/powerpc is a bad idea.
No one will make software for the emulator.
Amiga 68k is not a bad computer, but 68k is too slow.
What we really need is to add powerpc to fpga.
Fast 68k does not exist, the mythical 68k from natami exists only in a sick imagination of gunnar von boehn.
In other news Gunnar, Jens and Chris just tested the new Phoenix Demo on Majsta's Vampire 600 using ECS chipset, 16 bit fast memory and a too small Cyclone II fpga:
http://www.apollo-core.com/bringup/roto64.jpg
Not only is the demo working but that 31 in the upper left hand corner is the frames per second (fps). Here are some other results:
A4000/040 = ~7 fps
A4000/030 = ~3 fps
A600/TG68 = ~3 fps
A600/TG68-020+cache = ~5 fps
AMIGA 1000 (fastmem) = <1 fps
A1200 68030@50 = ~5 fps
A1200/1260@80MHZ = ~19 fps
3000T CSMK3 68060@75MHz = ~20 fps average (15-28fps)
A600/Phoenix = 31 fps
The CSMK3 68060@75MHz is my Amiga. The Phoenix demo is here:
http://www.apollo-core.com/phoenix_demo4
The reason why the 68k is slower than other processors is that no large companies with deep pockets are developing it. Of course the 68060 is slow, now :).
PowerPC is the only reasonable solution for the Amiga in an FPGA.
There is a comparison of the old Apollo core with the PowerPC 440 core in fpga:
http://www.apollo-core.com/index.htm?page=performance
I believe the 68k register memory architecture is better able to take advantage of the large memory bandwidth of an fpga than the load/store architecture of the PowerPC (and most other RISC fpga cores). High clock speeds are not necessary for strong performance when the processor can work directly in memory where there is plenty of memory bandwidth. This is even better when it can work in memory in parallel. We will have to wait for the Apollo core for this as the Phoenix core is just a single integer unit (68060 has 2 integer units).
-
That speed... is it because of the better memory speed or is it because the core has been optimised?
It's impressive.
-
Adding x86 or arm to the fpga to emulate 68k/powerpc is a bad idea.
No one will make software for the emulator.
Amiga 68k is not a bad computer, but 68k is too slow.
What we really need is to add powerpc to fpga.
Fast 68k does not exist, the mythical 68k from natami exists only in a sick imagination of gunnar von boehn.
x86 and arm as litte endian processors do not allow for integration with existing software.
SPARC, Itanium, Z * from IBM are too expensive.
MIPS, SH4 are too slow.
PowerPC is the only reasonable solution for the Amiga in an FPGA.
Just run 68K code in UAE and use AROS for the ARM/x86. Might not be the perfect solution, but considering cost and man power, it's the only viable solution.
-
That speed... is it because of the better memory speed or is it because the core has been optimized?
It's impressive.
The memory speed and bandwidth are good but the fast memory is only 16 bit and the chip memory is still super slow. Optimizations can get around some of these barriers obviously. I would say a good design and some optimizations help to minimize the bottlenecks. My understanding is incomplete though.
-
Are there any details of what the Phoenix core is, compared to the Apollo core?
Getting ~140MHz '060 performance is amazing, if true. Maybe this benchmark is rather slanted towards running well on the Phoenix core, which may be very fast at specific operations that normal 68k processors aren't fast in.
-
Petunia (OS4) or Trance (in MorphOS) is more of a binary translator/recompiler than it is a emulator/simulator; it basically recompile the 68k bytestream into native PPC code. This makes sense on a big endian HW architecture like PPC, because it makes it possible to mix "68k code" with PPC code in the same environment and run old and new programs (and OS components as well, like ARexx for examples) in the same environment as they were no different to each other. In fact they *aren't* different, both 68k and PPC apps are all de-facto PPC native at runtime, being scheduled by the same scheduler, sharing the same memory and system resources, etc. In this way, both MorphOS and OS4 *is* the native Amiga environment, where both new and old applications runs side by side, but on a different HW platform.
This isn't really possible on a little endian platform though, and AROS has a different approach where UAE is used to emulate a complete Amiga machine (with 68k CPU, custom chips and the whole shebang). The upside of this is an improved compatibility with very old SW and/or HW hitting applications, but the downside (compared to the MorphOS/OS4 approach) is that the Amiga apps runs "sandboxed" inside this emulated Amiga, and the AROS native ARM/x86 apps runs outside this box under AROS.
A terrible idea if you ask me. There are mainly two groups of Amiga users today, those who are here for the "classic", who are more of retro fans today, and those who are here for "NG", which is more about evolution than retro. The retro people use real Amigas, or emulators, or "new classic" HW like Minimig.
A product like you are talking about would not suit the retro fans, since they are more interested in "the real deal" and 100% compatibility (and like it or not, new HW compromises backwards compatibility). And the "NG" fans will feel the platform is being held back by 20 year old museum level technology. So it would be stuck in the middle, not really satisfying any of the groups.
IMHO of course! ;)
:)
I'm not sure where MorphOS fits into this discussion, as should it move to ARM it will probably have a lot less legacy compatibility.
Currently, NG OS' focus on a familiar environment and API support.
As they advance, these features are likely to be broken.
-
Are there any details of what the Phoenix core is, compared to the Apollo core?
Getting ~140MHz '060 performance is amazing, if true. Maybe this benchmark is rather slanted towards running well on the Phoenix core, which may be very fast at specific operations that normal 68k processors aren't fast in.
I don't expect the single integer pipe Phoenix to normally outperform a 68060 at the same clock speed. It's more comparable to a 68040 and was clocked around 90-100MHz last I checked. However, the 68060 has some bottlenecks which make it underperform a 68040 at the same clock speed in some cases. I didn't post to compare the overall performance of Phoenix by this early demo but rather to show that the 68k can have good performance in a fpga. Much more is possible in a larger but still affordable fpga. I think the performance of a 68060 can be exceeded. Apollo is designed for superscalar with 2-3 integer pipes that are each stronger than the 68060 and without the bottlenecks. From my limited understanding, the potential looks amazing.
-
I'm not sure where MorphOS [OS4] fits into this discussion
Read the thread backwards from my post, and it should become clear to you!
;)
-
A 1GHz Cubox i-series ARM machine can hit 30fps when streaming 1080p from the Internet. Why put an FPGA on it?
I like the FPGAArcade Replay board but it would never complete with the Cubox in price.
The Replay will go for $299 and the Cubox-i1 goes for $59. The quad-core Cubox-i4Pro is $139. All we really need is a multithreaded AGA core in the emulator and AROS/ARIX will do the rest.
-
A 1GHz Cubox i-series ARM machine can hit 30fps when streaming 1080p from the Internet. Why put an FPGA on it?
I like the FPGAArcade Replay board but it would never complete with the Cubox in price.
The Replay will go for $299 and the Cubox-i1 goes for $59. The quad-core Cubox-i4Pro is $139. All we really need is a multithreaded AGA core in the emulator and AROS/ARIX will do the rest.
I have to agree here, that said I find the FPGA projects really fun :)
-
Sounds like the Phoenix core is looking good. Shame if the Replay FPGA is too small to include it, I assume that's the case with the rest of the current "Amiga" FPGA boards (MCC216, MiST, Chameleon). What about the Acube Minimig+ is that big enough, I assume the Phoenix core could outperform the Dragonball on it. To get back on topic what we need is an "Amiga" FPGA board with a Cyclone 5 SoC FPGA. Has anybody ported Minimig to one of the dev boards like the SOCkit yet?
-
Sounds like the Phoenix core is looking good. Shame if the Replay FPGA is too small to include it, I assume that's the case with the rest of the current "Amiga" FPGA boards (MCC216, MiST, Chameleon). What about the Acube Minimig+ is that big enough, I assume the Phoenix core could outperform the Dragonball on it. To get back on topic what we need is an "Amiga" FPGA board with a Cyclone 5 SoC FPGA. Has anybody ported Minimig to one of the dev boards like the SOCkit yet?
The newest version Mist board has a large enough fpga and it's Altera which we prefer (Altera Cyclone III with 25k LE). The board has some other limitations and otherwise offers less value than the fpga Arcade. The MiniMig+ fpga is less than half the size of the fpga Arcade fpga. I expect the Phoenix core will outperform the Dragonball CPU. The MCC216 and Chameleon have too small of fpga. Natami would have been a perfect development environment with a large enough fpga to play.
We also looked at making a retro I/O expansion board for standard fpga developer boards. It would be cheap to make. The fpga developer boards have modern I/O themselves but some is not easy to use from the fpga and may require accessing with an on board ARM processor.
-
A1200/1260@80MHZ = ~19 fps A600/Phoenix = 31 fps
So there was no progress in the past three years, and as three years ago NatAmi 68k performance reaches only 060 120 Mhz.
http://wap.amigaworld.net/modules/newbb/viewtopic.php?mode=viewtopic&topic_id=33800&forum=25&start=80&viewmode=flat&order=0
It's not enough. Amiga powerpc accelerators achieve better performance 17 years ago.
It does not make sense. The best solution for the Amiga FPGA would be adding powerpc processor to FPGA or using an FPGA with an already built in powerpc.
-
funny enough the only ppc accelerator attempt in the last years has been given up exactly like the coldfire projects. perhaps 68k emulation on a foreign processor is the only suitable way, but i doubt it will be ppc. one way or another one can be forced to do anything about the issue and since the only projects in progress at this time seems to be either fpga or genuine cpus any further talk about ppc leads to nothing. who wants ppc may go os4 or mos any time.
-
So there was no progress in the past three years, and as three years ago NatAmi 68k performance reaches only 060 120 Mhz.
Of course there was progress all along but many CPU units have to be working correctly to make visible progress. How many man years do you think it takes to produce a modern processor? How how long do you think it takes for 3 knowledgeable people to make a modern processor in their spare time?
It's not enough. Amiga powerpc accelerators achieve better performance 17 years ago.
It does not make sense. The best solution for the Amiga FPGA would be adding powerpc processor to FPGA or using an FPGA with an already built in powerpc.
What makes sense is debatable and depends on the application. A PowerPC chip with a small fpga for the Amiga custom chips could give good performance and compatibility with a good 68k emulator. The disadvantages are lack of control over the processor ISA and availability and the 68k emulation may be limiting. Designing a 68k in fpga gives full control to the designers. There can be advantages for integrating Amiga buses in a more compatible way and maybe even helping with SMT on the Amiga (duplicating cores in an fpga is easy). This makes a SoC design easier. The 68k has advantages in ease of programming, code density and working in memory over the PowerPC. Of course an fpga core would not be as fast as a professionally designed hard processor but I like this path. I have nothing against the PPC but I like 68k. I would like to see what it is capable of if Motorola hadn't abandoned it and had tried to improve it. You are free to develop your PPC project your way and I wish you luck. I may even buy it in the end if you make something nice for a reasonable price.
-
Why put an FPGA on it?
because emulating aga in software introduces lag.
-
@matt, trying this phoenix demo under winuae on my surface pro gave me around 37fps. isnt that a little low in comparison? probably it rather reflects memory throughput than cpu speed, gunnars favorite argument if i recall well.
-
@matt, trying this phoenix demo under winuae on my surface pro gave me around 37fps. isnt that a little low in comparison? probably it rather reflects memory throughput than cpu speed, gunnars favorite argument if i recall well.
The Phoenix demo is not a very good test of CPU speed. However, a certain amount of processing power is needed to have a good frame rate. The demo shows that Phoenix has good performance and potential despite the scaled down core. It makes me wonder how much performance the full Apollo core would have in a larger fpga. Then I wonder how much rendering power the Apollo core would have with a fast fpga Amiga chipset like the Natami would have been. I don't think the 37 fps of UAE would be very difficult to beat.
-
right.
judging by the link the demo relies on 64bit multiplication, so thats probably where this softcore scores the best. but the actually good news is that it runs already on vampire. would be fun to have more details.
-
I like the idea of adding an FPGA to our existing PPCs.
JIT 68K translation would be much quicker than implementing the 68K in the FPGA and would leave room for chip set enhancements.
Running 68K and PPC code concurrently on processors operating at up to 2.7 GHz would greatly outperform any solution involving only the 68K.
A complete melding of legacy and NG environments.
What do you think?
-
dual core g5 running one core 68k and the other powerup? no, thanks. pure 68k code runs everywhere: amigas, uae, amithlon, fpgas, os4, mos, aros, pick your choice, no need for any further strange ideas.
-
right.
judging by the link the demo relies on 64bit multiplication, so thats probably where this softcore scores the best. but the actually good news is that it runs already on vampire. would be fun to have more details.
I don't believe there was room for 64 bit integer multiply in the Phoenix core so it's like the 68060 in this regard. There had been talk of letting multiply and division execute OoO while the processor continues provided that there are no dependencies. The 68060 is in order for integer multiply and divide and only the first pipe can be used. With a few more resources, the 68060 could have had 1 cycle 16x16=32 in both pipes which would have quadrupled the most common multiply performance. That and adding SWAP into the second pipe would have been simple and provided a nice boost in performance. As for details on Phoenix, I think the team is too busy playing right now ;).
I like the idea of adding an FPGA to our existing PPCs.
JIT 68K translation would be much quicker than implementing the 68K in the FPGA and would leave room for chip set enhancements.
Running 68K and PPC code concurrently on processors operating at up to 2.7 GHz would greatly outperform any solution involving only the 68K.
A complete melding of legacy and NG environments.
What do you think?
It's not a bad idea if implemented correctly. It could probably be done cheaper and with better performance that a 68k in fpga. An fpga 68k can have better integration with the Amiga chipset and an eventual Amiga SoC could be created. An ASIC of the SoC may outperform the PPC setup (CPU+SoC performance) and has advantages. The cost could then be cheaper with enough unit sales. It's 2 totally different concepts but neither is bad. The PPC way could almost be done on the SAM with it's Lattice fpga but it's too small. Maybe the CIAs could be implemented ;).
-
i think something like this is on schönfelds list, but he apparently aims for mips. curiously he always claimed ppc were unstable by design, if hard to comprehend how they could get away with major flaws all these years.
-
i think something like this is on schönfelds list, but he apparently aims for mips. curiously he always claimed ppc were unstable by design, if hard to comprehend how they could get away with major flaws all these years.
I think he might have been referring to the development path and supply of actual chips, which has never been particularly good. Even when Apple were using the chips, supply was poor due to Apple buying up all the Desktop/laptop grade units.
-
i think something like this is on schönfelds list, but he apparently aims for mips. curiously he always claimed ppc were unstable by design, if hard to comprehend how they could get away with major flaws all these years.
You can say a lot about PPC, but a statement that this architecture would be more unstable than any other (individual flawed chips/designs aside) is indeed difficult to "buy"...
-
I like the idea of adding an FPGA to our existing PPCs.
It would be like a ball and chain. Crippling. And expensive. And pointless. But other than that... ;)
-
@bloodline, tmhg
well, he actually wasnt refering to supply but to own experience with designing devices, routers, such as his nequester. the technical difficulties with reaching desired stability have in his own words resulted in that he turned his back at ppc. even though statement as this seems unbelievable even to me, who is not a ppc lover, i either im able nor want to question his technical expertise, so i just leave it open.
just for the sake of interest here a genuine statement paradroids on a1k concerning the ppc controversy (english speakers will have to use some translator service, sorry):
http://www.a1k.org/forum/showthread.php?p=445998&highlight=ppc#post445998
-
@above
You like the PowerPC to program in assembler?
I've never tried, but it looked several times harder than 68k.
-
@above
You like the PowerPC to program in assembler?
I've never tried, but it looked several times harder than 68k.
I've never tried, but it looked several times harder than 68k.
Not really, its just more instruction names to remember move does many things on 680x0 depending on syntax with '(' and ')' or whit out, PowerPC assembler does not have that.
Most PowerPC instructions have 3 parameters, parameter 1 and 3 is normally source and destination, number 2 is often optional, normally used for indirect addressing.
Etch of the letters in the instruction normally stands for some thing, if you remembering what letters stand for you can guess what the instruction does easily. If you spent just as much time whit PowerPC as 680x0 you remember the names.
'S' Store
'L' Load
'Z' Zero
'R' reverse order (little endien mode).
'X' Indexed addressing.
'B' Branch
And so on.
-
@above
You like the PowerPC to program in assembler?
I've never tried, but it looked several times harder than 68k.
PowerPC uses too many acronyms and aliases for the mnemonics. It is tedious and tricky to program efficiently being a load/store architecture but it does have more instructions than most RISC processors (the down side being some instructions are missing from the hardware of some PowerPC processors). Most instructions have 3 operands which is convenient. More has to be done manually and considered than the 68k which is auto everything and forgiving. Other than that, PowerPC is a clean and consistent 32 register load store architecture. It's actually similar in many ways to the new ARMv8 ISA.
The 68k is still much easier to program and debug. It's simple (mostly 2 operands) and consistent (unlike x86) with powerful addressing modes for working directly in memory. I love the tiny programs which helps performance also. It's the easiest and funnest halfway modern CISC processor. It could use some modernization where ease of use and code density can be improved more.
-
PowerPC uses too many acronyms and aliases for the mnemonics. It is tedious and tricky to program efficiently being a load/store architecture but it does have more instructions than most RISC processors (the down side being some instructions are missing from the hardware of some PowerPC processors). Most instructions have 3 operands which is convenient. More has to be done manually and considered than the 68k which is auto everything and forgiving. Other than that, PowerPC is a clean and consistent 32 register load store architecture. It's actually similar in many ways to the new ARMv8 ISA.
Actually I noticed there was a slight similarity too, probably due to the 32 registers and inherent 64bit support. But the ARM v8 is very very clean, and not really meant for human eyes.
The 68k is still much easier to program and debug. It's simple (mostly 2 operands) and consistent (unlike x86) with powerful addressing modes for working directly in memory. I love the tiny programs which helps performance also. It's the easiest and funnest halfway modern CISC processor. It could use some modernization where ease of use and code density can be improved more.
68k is by far the nicest "CISC", and is assembly featured in my life I would opt for it... But the compiler (clang specifically) rules my coding now :)
That said, I totally love these 68k FPGA projects and think there is a place for them in our amiga world!
-
It would be like a ball and chain. Crippling. And expensive. And pointless. But other than that... ;)
Not really, as most NG code wouldn't use it.
And bit banging legacy code could.
Obviously running that would slow the system down, but only by choice.
And if it was supported by ASMP, no slow down of the other cores.
-
Clone-A with powerpc is exactly what is needed for Amiga community.
Really a pity that Jens to quickly gave up on that idea.
Not emulated 68k with AGA plus not emulated powerpc it would be really interesting.
-
Clone-A with powerpc is exactly what is needed for Amiga community.
its just your opinion. doesnt look that there are that many who back you up.
Really a pity that Jens to quickly gave up on that idea.
as you may have read from the link i have posted, he has his reasons. he said he will only consider it if someone will pay the whole development up front, now its up to you. making demands is easy.
-
Clone-A with powerpc is exactly what is needed for Amiga community.
Really a pity that Jens to quickly gave up on that idea.
Not emulated 68k with AGA plus not emulated powerpc it would be really interesting.
Well, you have one naysayer.
I like the idea.
-
Well, you have one naysayer.
you mean jens? and how do we call people who now and then pop up with all kinds of proposals what others could do, to please them?
I like the idea.
what can i say, guys.. start developing. because providing results is a part that actually convinces people, y know.
-
its just your opinion. doesnt look that there are that many who back you up.
Most of the PowerPC fans are on other web sites waiting for cheap PowerPC hardware and SMP to lead them to the promised land. Anyone creating new PowerPC hardware had better ask (pay) for support before going too far. Another option is to reverse engineer hack and patch WOS more than it already it is. The best option, and the open option these PowerPC fans don't realize they need yet, is to improve AROS PPC. That is what would make PPC+fpga Amiga custom chip projects feasible. Without it, these projects are probably dead in the water and will never gain momentum (look at the UltimatePPC accelerator). If AROS PPC is improved enough, it could surpass AmigaOS 4 and MOS drawing their users into one open (and cheaper) PowerPC Amiga platform. This would in turn create demand for more PowerPC hardware. Now that I have given away the secret to new cheaper PowerPC hardware, maybe they will jump over to the AROS web site and demand new PowerPC development like they are demanding new PowerPC hardware here ;).
-
i beg to differ, aros ppc is as it seems almost as obsolete as 68k. as example aros mesa is about to be working at least software wise, lets call it "wrong colors stuff". aros maintainer, deadwood, has understandibly no much motivation to seek endian dependencies within the genuine engine source. i have had a brief contact with our ppc linux expert (xeno) about the issue, and he said, the interest to fix endianness issues in mesa, which concerns both 68k and ppc, is limited to tell the least. so as much as i hate it to be the case, as 68k fan, big endian platforms ppc and 68k, are fading together into the obscurity as we look at it.
-
i beg to differ, aros ppc is as it seems almost as obsolete as 68k. as example aros mesa is about to be working at least software wise, lets call it "wrong colors stuff". aros maintainer, deadwood, has understandibly no much motivation to seek endian dependencies within the genuine engine source. i have had a brief contact with our ppc linux expert (xeno) about the issue, and he said, the interest to fix endianness issues in mesa, which concerns both 68k and ppc, is limited to tell the least. so as much as i hate it to be the case, as 68k fan, big endian platforms ppc and 68k, are fading together into the obscurity as we look at it.
Sure the 68K is dead, but there are enough of them that I've got a large stock I am using on a couple of projects.
And not to counter your "expert" opinion, but Power development is ongoing.
Freescale has developed new 64 bit PPC cores, and IBM is opening up Power 8 development.
Power processors will be here for some time to come.
And, of course, if I really want to invest in an alternate with the right "endianess" there is always ARM which looks to have a bright future.
An Amiga/MorphOS solution with a 64 bit AMD ARM processor with built-in AMD/ATI graphics would suit me fine.
-
i beg to differ, aros ppc is as it seems almost as obsolete as 68k. as example aros mesa is about to be working at least software wise, lets call it "wrong colors stuff". aros maintainer, deadwood, has understandibly no much motivation to seek endian dependencies within the genuine engine source. i have had a brief contact with our ppc linux expert (xeno) about the issue, and he said, the interest to fix endianness issues in mesa, which concerns both 68k and ppc, is limited to tell the least. so as much as i hate it to be the case, as 68k fan, big endian platforms ppc and 68k, are fading together into the obscurity as we look at it.
I'm aware that AROS PPC is the deadest branch of AROS. I'm also aware that developing AROS PPC would help to fix big endian bugs. I'm also aware that AROS PPC gaining in popularity would unify the Amiga API. I also prefer 68k over PPC but developing AROS PPC would help the Amiga so I encourage it's support. Neither the 68k or PPC path are necessarily the correct or easiest choices. PPC seems to be slowly dieing and the 68k is old and little developed (it can be emulated easier on other processors though). ARM makes the most sense for low end power efficient processors and x86_64 makes the most sense for affordable performance processors.
And, of course, if I really want to invest in an alternate with the right "endianess" there is always ARM which looks to have a bright future.
An Amiga/MorphOS solution with a 64 bit AMD ARM processor with built-in AMD/ATI graphics would suit me fine.
ARM is natively little endian. It can switch to big endian mode but there are disadvantages like with the PPC switched to little endian mode. I don't like the bi-endian processor concept that changes endianess with a control bit. I prefer instructions or MMU mappings for converting the endianess.
-
ARM is natively little endian. It can switch to big endian mode but there are disadvantages like with the PPC switched to little endian mode. I don't like the bi-endian processor concept that changes endianess with a control bit. I prefer instructions or MMU mappings for converting the endianess.
Right now, I'd prefer to keep developing PPC based systems.
We have them, new systems are about to be introduced, and there are other processors that could be explored.
And its basically our ISA to exploit.
Outside of Linux, there are few other alternative OS' for this ISA.
Amiga OS4 and MorphOS run on PPCs and AROS can too.
We have a software base we can expand from NOW.
And 68K software can run pretty seamlessly on a PPC.
If you doubt me, check out a MorphOS or AOS4 demo.
And with further advances (like the FPGA we've mentioned), Amiga code could run even better.
These approaches are considerably better than relying solely on UAE, they can run software faster AND support continued development under the same API.
Anyone who is fixated on the 68K needs to investigate further.
Development of 68K software can still be carried out (and is) on NG platforms and it can be run concurrently with native applications that can interact with that code as intended in our older OS'.
I don't mean to sound too evangelical.
But I was a 68K system integrator and developer and I LOVE having this tool in my hands.
-
I would suggest that the features of a PowerPC Amiga is lacking. It can run a lot of 68k programs, others have to use emulation. Really that is unfinished. So you have to go to the bother of having more than one machine/set up.
Maybe when the current projects are finished someone will try a new PowerPC card.
-
We have a software base we can expand from NOW.
And 68K software can run pretty seamlessly on a PPC.
If you doubt me, check out a MorphOS or AOS4 demo.
Next to endianess you also have the packing of data types in a C struct. The native packing of PPC and m68k is different so the seamless running of m68k on PPC is only possible because special non-PPC native packing is done on data structs that are to be used by legacy m68k software on PPC.
On AROS we preferred efficiency over backwards compatibility and at the time PPC AROS was live we decided to always use native struct packing. This means m68k software does only run under emulation on AROS PPC.
Although different AROS devs have different opinions I still stand by this choice. People who want a PPC Amiga-like OS with seamless running of m68k software can already use MorphOS or AOS4.
I do think emulation of m68k in AROS can be more integrated using a system like on Linux now: if you want to run 32-bit programs on a 64-bit system you need the 32-bit libraries used by that program. For the rest the program will show up as any other program. So to run m68k on a AROS with another CPU you need the AROS m68k libs but the GUI will be shown next to native programs, DOS mounts are shared, clipboard is shared etc.
-
Next to endianess you also have the packing of data types in a C struct. The native packing of PPC and m68k is different so the seamless running of m68k on PPC is only possible because special non-PPC native packing is done on data structs that are to be used by legacy m68k software on PPC.
On AROS we preferred efficiency over backwards compatibility and at the time PPC AROS was live we decided to always use native struct packing. This means m68k software does only run under emulation on AROS PPC.
Although different AROS devs have different opinions I still stand by this choice. People who want a PPC Amiga-like OS with seamless running of m68k software can already use MorphOS or AOS4.
I do think emulation of m68k in AROS can be more integrated using a system like on Linux now: if you want to run 32-bit programs on a 64-bit system you need the 32-bit libraries used by that program. For the rest the program will show up as any other program. So to run m68k on a AROS with another CPU you need the AROS m68k libs but the GUI will be shown next to native programs, DOS mounts are shared, clipboard is shared etc.
You'll note Staf, that I didn't include AROS in my comment.
However, I wasn't aware that using the AROS m68k libs was an option.
Pretty cool.
-
You'll note Staf, that I didn't include AROS in my comment.
My reaction was also partly to matthey who was lobbying for using AROS PPC as the mother of all Amiga-like OSes.
However, I wasn't aware that using the AROS m68k libs was an option.
Pretty cool.
It's an option if somebody implements it; unfortunately it is not ATM.
greets,
Staf.
-
My reaction was also partly to matthey who was lobbying for using AROS PPC as the mother of all Amiga-like OSes.
That should probably read "My reaction was also partly to matthey who was lobbying for using AROS PPC as the mother of all PPC Amiga-like operating systems." It's a minor change but important difference ;).
-
And, of course, as a fanatical MorphOS user I'd have to say that we already have "the mother of all PPC Amiga-like operating systems" (which, btw, contains some AROS derived components).
-
People who want a PPC Amiga-like OS with seamless running of m68k software can already use MorphOS or AOS4.
MorphOS and AOS4 aren't equivalent though. Doesn't the different padding also mean that PPC software that runs on MorphOS or AOS4 can't ever be compatible with AROS either?
It seems that decision marginalises AROS PPC.
-
So to quote Sam Raimi, "Join US".
I tried to lure Staf over, but he's too busy with AROS X86.
When you compare X86 and PPC AROS, the latter does seem pointless.
-
No. You can run AROS on an old Mac. He didn't mention that was the target platform.
-
I tried to lure Staf over, but he's too busy with AROS X86.
I hate to say it but recently my interests went to things not directly (NG) Amiga related. Things like RTL hardware programming, Cypress PSoC device, etc.
-
I hate to say it but recently my interests went to things not directly (NG) Amiga related. Things like RTL hardware programming, Cypress PSoC device, etc.
Understandable. I have been working on everything from 8 bit projects to FPGA programming.
But then, my NG of choice is pretty stable.
I don't know if everyone here knows how much time you've devoted to AROS.
I'm on the mailing lists, so I'm aware of how much you've contributed.
-
In other news Gunnar, Jens and Chris just tested the new Phoenix Demo on Majsta's Vampire 600 using ECS chipset, 16 bit fast memory and a too small Cyclone II fpga:
http://www.apollo-core.com/bringup/roto64.jpg
Not only is the demo working but that 31 in the upper left hand corner is the frames per second (fps).
(...)
A600/Phoenix = 31 fps
(...) The Phoenix demo is here:
http://www.apollo-core.com/phoenix_demo4
MorphOS 1.4.5 A1200 AGA BlizzardPPC = 500 fps
phoenix_demo4.jpg (http://skolman-mws.w.interia.pl/mos/phoenix_demo4.jpg)
;)
-
Why do you still want the PowerPC? Look here:
http://www.7-cpu.com/
The fastest G5 is not that much faster than Cortex A-15. But the G5 takes 75-100W power... and it doesn't seem there is going to be a successor.
What the PowerPC Amiga is going to look in 5 years? 3000$ machine with half the processing power of 300$ cell phone? Or maybe POWER8 monster so expensive, that hardly anyone can afford it, where using more than 1 core or more than 2GB RAM would require apps written in some strange, inefficient way - just to allow the system to maintain binary compatibility with legacy software ? Don't be silly - PowerPC is a dead end, ditch that bitch!
There are two reasonable ways to go: x86 and ARM. And don't even think about OS4/MorphOS-style m68k compatibility! We need multicore support. And 64 bit - 2GB RAM is what my tablet has, I really expect a desktop (even thin desktop) machine to have more (reasonable minimum for the photo processing software I use is 64-bit system with 4GB RAM...). This means API rework, so AROS-style would be the only possible way to achieve m68k compatibility. Help Toni Willen to integrate QEMU into UAE, and you will also be able to have PowerPC compatibility in a similar way.
-
Or maybe POWER8 monster so expensive, that hardly anyone can afford it, where using more than 1 core or more than 2GB RAM
The Power8 box, that I daily work on has 4 Terra byte main memory :-)
Now what?
-
So what? How much did this Power8 box cost? Will the average Amiga fan be able to buy it (afford it)? How can the current AmigaOS software use the potential of this machine? How much potential can you use by utilizing current API/ABI?
One more thing - we also need memory protection and multiuser. Ultimately, a way to run ARM software on x86 or vice-versa using the JIT engine (QEMU again?). Sorry - XXI'th century...
-
So what? How much did this Power8 box cost?
Over $100,000
And yes this box is big and has 80 cores , and _no_ Amiga OS does not support it.
There a big POWER machines build today and also bought for a lot of money.
So POWER is by far not dead.
What your interest is in "very small" machines.
And yes in this segment there are currently not really POWER offerings.
All new POWER systems that are sold in the last years a real big systems.
But POWER is now "open".
You know this right?
This means "Mr Chinese company" could take a POWER Chips design today
and tomorrow sell a POWER based laptop, or netbook or what ever.
This could happen or maybe not - I don't know - you don't know.
What I would not do here - is running now around and tell the people that build hardware for a living - what they should do.
Believe me the people have choosen PPC for their systems for a reason.
Whether this reason is valid today - maybe - maybe not.
But anywhich way these people will be totally aware of all this.
And do not need yours or mine advice.
So save your breath... You will anyway not change anything with it.
-
Why do you still want the PowerPC? Look here:
http://www.7-cpu.com/
- PowerPC is a dead end, ditch that bitch!.
No, and repeating it over and over again wount make it any more true.
-
Over $100,000
And yes this box is big and has 80 cores , and _no_ Amiga OS does not support it.
There a big POWER machines build today and also bought for a lot of money.
So POWER is by far not dead.
What your interest is in "very small" machines.
Because I'm just a poor, simple guy - there is no way I can spend $100,000 on a home machine. Core i7 4790k (one chip, no more) based PC is really the maximum I could possibly afford.
But POWER is now "open".
You know this right?
This means "Mr Chinese company" could take a POWER Chips design today
and tomorrow sell a POWER based laptop, or netbook or what ever.
This could happen or maybe not - I don't know - you don't know.
Believe me the people have choosen PPC for their systems for a reason.
Believe me - no "Mr Chinese company" is currently selling a POWER based laptop for a reason. AmigaOS / MorphOS teams can either wait till this happen ("two more weeks"?), or use the currently available chips. What do you think, which choice is more likely to result in a product ready to sell?
Even if we would have such a Power chip at affordable price and decent performance - what changes would the AmigaOS / MorphOS need to fully utilize its capabilities? Would it be possible to keep the current API, or maybe some big jump would be needed, comparable to ARM/x86 migration?
-
MorphOS does not need to wait. Already have laptops that can run the OS for some time
-
Great! Where can I buy a brand new one?
-
You cant buy brand new hardware for MorphOS. anymore. Good isn't it. Makes it much much much much cheaper.
-
If these laptops are 10 years old PPC Macs, then go back to post #66.
-
If these laptops are 10 years old PPC Macs, then go back to post #66.
Ahhhh post #66 it's not very well thought out though is it really.....
-
The Power8 box, that I daily work on has 4 Terra byte main memory
You got a pre-release model? I can't remember the full 4 being an option on the released boxes?
I hope we can get our 822 up this or next week (it arrived while absolutely nothing happened in the summer and just about everyone was away - sucks to come in and start on first day after the vacation...)
-
You might like the FPGA arcade or other FPGA. You could get to a 200mhz 060 equivalent soon.
-
In regards to byte ordering, x86 can use either le or be. Granted for decade old stuff it comes at a performance hit, but even then you're left with more performance than ppc can offer. Newer gear even has instructions to do it in hardware.
I dont really care for any "versus" crap, but even more irritating is this communities obsession with recycling info. that years and years ago was partially true and running with it regardless of the truth.
-
On the OP, this sounds like a dumb idea. As said, you're basically doing what Nintendo did with the SA-1 in the SNES game Super Mario RPG: Enhancing one part while leaving the rest untouched.
I really wish Commodore would have diversified the Amiga market. If they made a low cost server with a 68k and OCS combo chip around the time of 1992 then they'd have gotten a toe hold in the low cost server market, especially for people new to server administration. It may have not been super secure, but since Amiga in the 1990s was a poor man's SGI more or less, take a page from their book.
I would like to see the guys at A-EON do a small desktop version of the SGI Onyx2 cube design, and do something like this:
PowerPC or SPARC or MIPS quad core
DDR3 RAM up to 32GB
NUMA bus system
I'm a believer in keeping it simple and staying away from needlessly complex architectures. SPARC, for instance, is RISC, Big Endian and has open designs, plus Fujitsu manufactures tons of them for the server market. SPARC compares favorably to x86_64 if you compare similar die sizes and CPU classes. They're also a parallel orientated design which is where technology is going to move. Moore's law has been hit for clock speeds and the marketing behind that is slowly fading, but we can thank Intel and NetBurst for that, bunch of morons. So parallel, moderately clocked designs will become the norm. Even x86 is now becoming more RISC-like internally, converting the more orthogonal instructions to simpler ones with microcode.
68k was good for the time, where orthogonal instructions were useful, but today all this FPGA design effort is largely fruitless when the fact is the hobby of Amiga computers is going to die out. I like having Nia around, but usefulness is taking priority these days. Orthogonal instructions are largely useless waste of die space when MIPS for instance is simpler by a magnitude and is able to work with the fact that memory access is very fast now and we don't need to have very lengthy instructions fed to the CPU when it is faster now to do short concise instructions. Even Itanium and EDGE emphasize this with instruction parallelism, which while applying CISC concepts to RISC actually compliments the architecture to the point that one engineer I know described it as Super-RISC.
-
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.
-
@fishy_fiz
"Why would A-eon make a board supporting 16* the memory the os its designed for?"
x86/x64 OS roots are from 640k system, so OS can evolve, better not limit the HW too much.
A-eon has but signifficant effort to Linux for their HW and also AOS is breaking the 2GB barrier. (IIRC, PA6T can already address 16 or 32GB, P5020 can address 64GB)
-
x86/x64 OS roots are from 640k system, so OS can evolve, better not limit the HW too much.
What are you trying to say?
-
Once again, yet another idiot trying to convince us Amiga users to resign from the powerpc.
We Amiga users use powerpc because it is the fastest and COMPATIBLE solution.
Powerpc exists, it works, anyone can buy and use.
As in 1997, so 2014.
x86,ARM are cool but because it is low endian they are incompatible,
and therefore useless.
And as in 1997, in 2014 emulators on x86 is still slower than powerpc.
It is boring this whole %&$#?@!%&$#?@!%&$#?@!%&$#?@! "powerpc is evil".
Years of bull%&$#?@!%&$#?@!%&$#?@!%&$#?@! but with no effects, powerpc haters can only talk but they are too stupid and too lazy to do something.
Powerpc is the best solution in the same way 17 years ago and now.
And that's why we Amiga users will still use powerpc.
-
He has a point that there are no POWER-PC offering in the "user-price segment".
IBM does produce very good POWER chips for servers in the price segment of $20,000 and plus.
But there is a "hole" in the user segment.
You can go out and buy a good x86 Laptop today for $500
You can not get a PPC laptop.
Of course talking here about it will change nothing...
If you compare it with cars then
* IBM is selling FERRARIS
* AMIGA hardware are fast as a FIAT-PANDA but are sold with a price tag of a Ford Mustang.
Its understandable that users would prefer to pay either FIAT-PANDA prices for PANDA performance
or they want at least Mustang performance for the price the pay.
-
Once again, yet another idiot trying to convince us Amiga users to resign from the powerpc.
We Amiga users use powerpc because it is the fastest and COMPATIBLE solution.
Powerpc exists, it works, anyone can buy and use.
As in 1997, so 2014.
x86,ARM are cool but because it is low endian they are incompatible,
and therefore useless.
And as in 1997, in 2014 emulators on x86 is still slower than powerpc.
It is boring this whole %&$#?@!%&$#?@!%&$#?@!%&$#?@! "powerpc is evil".
Years of bull%&$#?@!%&$#?@!%&$#?@!%&$#?@! but with no effects, powerpc haters can only talk but they are too stupid and too lazy to do something.
Powerpc is the best solution in the same way 17 years ago and now.
And that's why we Amiga users will still use powerpc.
Lately it seems that AmigaOS supporters seem to prefer harsh words :)
People are not "hating" PowerPC, it more seems to me that some people take every critic or preference as personal attack
PowerPC is not a bad architecture but it has lost the race. Everything is about money, developing new processors is time consuming and expensive. Today money goes either in something Intel/AMD or ARM related so these both platforms develop, there is not much money going in PPC and because it is not used for desktops anymore there is no money going in processors that are capable, money goes in processors either for embedded systems or servers. It is simple economics, no market means no money to earn means no investment. Even PowerPC geeks cannot deny basic rules of economy. With existing options the market (1000+ user) can exist for a while, that is all. The platform will lag more and more behind, first class will be just the price. When you are happy with that it is ok, at the moment it is pure hobby market with no money to earn. If you want to change that PowerPC is the wrong choice.
-
PowerPC is not a bad architecture but it has lost the race.
Its very simple...
There are two main companies building POWER/PPC CPUs.
These are IBM and MOTOROLA aka FREESCALE.
IBM is _only_ interested in the high end server market.
Therefore they only produce high end servers.
Freescales PPC customers are telecom/router manufacturer.
So Freescale of focuses on producing chips which are ideally suited for there customers.
Doing a CPU development costs roughly about $50,000,000 USD.
Neither IBM nor Freescale have any customers using the PPC in the desktop / home -pc market segment. So taking a lot of money and building a CPU for no customers - makes really no sense to them.
The Antaris aka 970 aka G5 CPU was a desktop version of the IBM POWER-4 CPU.
Since then no desktop-CPU was build.
But IBM did continue to improve the POWER chips,
After POWER4 came POWER5, then POWER 6, then POWER 7, and now you can buy POWER 8.
So IBM did improve the POWER continuesly. And continues to do this.
But in the "user" segment you do not see this.
The same is with Freescale. Freescale continued to improve their PPC offering -
but in the market segment which their customers did demand.
-
We Amiga users use powerpc because it is the fastest and COMPATIBLE solution.
A decent PowerPC emulator running on a top of the line x86 will be cheaper and faster than any Amiga hardware available.
I'm not so convinced that ARM could do the same.
For old school Amiga users who never used a PowerPC there is very little reason to be able to run PowerPC software.
-
Once again, yet another idiot trying to convince us Amiga users to resign from the powerpc.
We Amiga users use powerpc because it is the fastest and COMPATIBLE solution.
Powerpc exists, it works, anyone can buy and use.
As in 1997, so 2014.
x86,ARM are cool but because it is low endian they are incompatible,
and therefore useless.
And as in 1997, in 2014 emulators on x86 is still slower than powerpc.
It is boring this whole %&$#?@!%&$#?@!%&$#?@!%&$#?@! "powerpc is evil".
Years of bull%&$#?@!%&$#?@!%&$#?@!%&$#?@! but with no effects, powerpc haters can only talk but they are too stupid and too lazy to do something.
Powerpc is the best solution in the same way 17 years ago and now.
And that's why we Amiga users will still use powerpc.
actually amiga users use 68k cpu family, simply because there is no amigas with ppc, arm, mips or x86 cpus, but this might be too hard to comprehend, i fear.
-
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.
-
Both MIPS and SPARC have open designs, which means A-EON could improve them without a license.
Are you aware of "OPEN POWER"?
-
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 (http://riscv.org/) instruction set architecture. Volume silicon manufacture is planned as is a low-cost development board
-
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 )
-
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?
-
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.
-
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.
-
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.
-
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.
-
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?
-
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."
-
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.
-
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.
-
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.
-
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.
-
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.
-
Why do we talk about this so long ?
Everybody with some "brain" sees immediately that moving to SPARC or MIPS would be no improvement over PPC at all.
* The Compilers for SPARC or MIPS are not any better than for PPC
* You would loose all existing PPC code. 68K to PPC Jit etc
* SPARC and MIPS are not faster than PPC
* There are no more or no better chips available for users
Is a silly proposal
-
@Linde
Maybe I'm not understanding your question, because I've been trying to answer it. Let me try again:
I prefer working with an architecture at a low level. The reason I give two %&$#?@!%&$#?@!%&$#?@!%&$#?@!s is because I actually would like to code some for Amiga down the line. Reason I don't now is simple: I am learning 68k assembler and that is one of the most tedious and pedantic languages I've learned because all the current compilers for C are too old and broken for OS 3.9 for me to use. I have been coding on a UNIX style C compiler such as Clang and that's how I intend to do this. GCC is a load of junk though so I may be forced to build my own compiler >_>. Anyways, back to my point: If the Amiga were to become x86 based I'd probably say screw it and not code for it because I have long given up optimising programs on x86 properly. Nothing about the tools I use exposes anything, rather, it is how I treat C as more flexible assembler. I like to be aware of the underlying hardware. With that said I'd probably stick to RISC boxes running BSD or some other UNIX if Amiga moved to x86.
@OlafS3
Ive got much different goals in mind than you: I never intend to make money off the code I write. I therefore could care less about what a user thinks. As a sysadmin as my day job I don't handle users or interact with them so I generally speaking don't care.
I'm just upset because I'd like to do some NG work since the toolchain and OS have a lot of expansion, but acquiring new and high performance hardware is impossible. I suggested a switch because it seems AEON and ACube are utterly incapable of building units at a reasonable cost/performance ratio. I could buy a whole rack of Onyx 350 IR4 graphics for the price of the X1000 and wipe the walls with it, especially since OS4 is a 32-bit, multiprocessor blind system.
AROS doesn't count for me since I dont own any powerful ARM or PowerPC hardware
@biggun
I REALLY don't appreciate being called stupid subversively. Currently there are plenty of more performant MIPS and SPARC chips available than most PowerPC gear. The R16000 of MIPS fame is faster despite being clocked lower, and a Sun Ultra 45 wipes the walls with a G5 and a PA6T. We're talking 10+ year old designs: It doesn't cut it! And if they adopt faster CPUs for the next NG Amigas, PowerPC ones I can expect the systems to be even more expensive.
As previously explained I could give a flying freak whether or not it would break binary compatibility. Sure other users care, but I care more about having a 64-bit OS with a CPU that can perform well today.
Don't feed anymore bull, you can look up the dhrystone measurements and other benchmarks yourself, but do keep in mind all of these systems are 64-bit and SMP capable so they're going to beat any slow uniprocessor 32-bit mode OS
-
@Linde
Maybe I'm not understanding your question, because I've been trying to answer it. Let me try again:
I prefer working with an architecture at a low level. The reason I give two %&$#?@!%&$#?@!%&$#?@!%&$#?@!s is because I actually would like to code some for Amiga down the line. Reason I don't now is simple: I am learning 68k assembler and that is one of the most tedious and pedantic languages I've learned because all the current compilers for C are too old and broken for OS 3.9 for me to use. I have been coding on a UNIX style C compiler such as Clang and that's how I intend to do this. GCC is a load of junk though so I may be forced to build my own compiler >_>. Anyways, back to my point: If the Amiga were to become x86 based I'd probably say screw it and not code for it because I have long given up optimising programs on x86 properly. Nothing about the tools I use exposes anything, rather, it is how I treat C as more flexible assembler. I like to be aware of the underlying hardware. With that said I'd probably stick to RISC boxes running BSD or some other UNIX if Amiga moved to x86.
@OlafS3
Ive got much different goals in mind than you: I never intend to make money off the code I write. I therefore could care less about what a user thinks. As a sysadmin as my day job I don't handle users or interact with them so I generally speaking don't care.
I'm just upset because I'd like to do some NG work since the toolchain and OS have a lot of expansion, but acquiring new and high performance hardware is impossible. I suggested a switch because it seems AEON and ACube are utterly incapable of building units at a reasonable cost/performance ratio. I could buy a whole rack of Onyx 350 IR4 graphics for the price of the X1000 and wipe the walls with it, especially since OS4 is a 32-bit, multiprocessor blind system.
AROS doesn't count for me since I dont own any powerful ARM or PowerPC hardware
@biggun
I REALLY don't appreciate being called stupid subversively. Currently there are plenty of more performant MIPS and SPARC chips available than most PowerPC gear. The R16000 of MIPS fame is faster despite being clocked lower, and a Sun Ultra 45 wipes the walls with a G5 and a PA6T. We're talking 10+ year old designs: It doesn't cut it! And if they adopt faster CPUs for the next NG Amigas, PowerPC ones I can expect the systems to be even more expensive.
As previously explained I could give a flying freak whether or not it would break binary compatibility. Sure other users care, but I care more about having a 64-bit OS with a CPU that can perform well today.
Don't feed anymore bull, you can look up the dhrystone measurements and other benchmarks yourself, but do keep in mind all of these systems are 64-bit and SMP capable so they're going to beat any slow uniprocessor 32-bit mode OS
AROS runs on almost any hardware available except SPARC and MIPS including X86/X64/PowerPC/ARM and 68k. If you search for something running on your two favorites you will have no luck.
-
Well of course. My sentiments exactly. If I'm gonna buy something high performance it has better be a good RISC CPU is my though, and for anything recent that leaves out PowerPC, ARM is too underpowered, so that leaves SPARC and MIPS.
Of course if A EON were to get a POWER7 based system with NUMA and reasonably priced around $1000-1500 at most, sure I'd pick it up. But the current offerings seem to be limited by cost and CPU availability. Why not then move to MIPS which has plenty of high performance designs available? Or SPARC which has processors sold from Fujitsu. I'm sure between those a lower cost yet high performance option exists!
-
Currently there are plenty of more performant MIPS and SPARC chips available than most PowerPC gear. The R16000 of MIPS fame is faster despite being clocked lower, and a Sun Ultra 45 wipes the walls with a G5 and a PA6T. We're talking 10+ year old designs:
The Sun ULTRA 45 came our 8 years ago - while the G5 came to market 12 years ago,.
Whether a old Sparc is faster than an much older PPC does not really matter.
The which AMIGA users migh interest is:
* being able to run existing software
* being able to buy good, new hardware for a reasonable price
PPC is least provides the first point.
-
You always circle around your two favorites but it will not happen. I do not think for different reasons that A-eon or Hyperion will ever change ISA and drop PPC but "if" they did the new platform would need big advantages compared to PowerPC to justify the expenses they need and the sacrifices that would needed f.e. dropping the existing 68k integration and the efforts needed to run old PPC software. And do not forget that the main programmers (the Frieden brothers) are paid for it and if the expenses can be regained after is unknown and a risk. And why do you think A-eon (one person) is interested to pay for a ISA change? I only know that he is prefinancing new PPC hardware. Hyperion wants to get paid for porting it by the hardware vendor, who do you think will be willing to do that?
-
You know what? It isn't even worth arguing over anymore. Screw it. I'm not being unreasonable and I'm certainly making a point that everyone seems to casually deny: that SPARC and MIPS are readily available, and offer more performance for less cost than our current designs. Sure it would cost money to move, but I can't imagine A EON is getting rich on the 100 or so X1000s sold. I also think I'm not alone in feeling alienated and cheated in that the performance offered is much less than I can get elsewhere.
The more I think about it though the more I see why nothing gets done here. Just too fragmented and resistant to change anything that may break compatibility.
-
If you're going to move anywhere you move to an architecture where there is an existing inexpensive desktop product that exists - like x86.
-
I'm not being unreasonable and I'm certainly making a point that everyone seems to casually deny: that SPARC and MIPS are readily available, and offer more performance for less cost than our current designs.
Please show use where we could buy new Laptops or new Desktop with these for < $500.
If you can do this - then your would have a reasonable point.
-
Gladly for MIPS: lemote.com/en/products
For higher performance stuff, a company like A-EON could take one of the open designs such as the OpenSPARC T1 and build boards off that for reasonable prices. It isn't as hard as you're postulating.
-
If you're going to move anywhere you move to an architecture where there is an existing inexpensive desktop product that exists - like x86.
Yeah and that will be the day I move to another NG product that doesn't do that. You don't realize the scope of issues that is going to cause. Look at BeOS/Be Inc. if you want to know what lies in store for anyone wanting to play with the big boys.
-
lemote.com/en/products
Available today? At what cost? Available tomorrow? There's no security there.
For higher performance stuff, a company like A-EON could take one of the open designs such as the OpenSPARC T1 and build boards off that for reasonable prices
Reasonable to who?? It would not be "reasonable" at low volume.
Yeah and that will be the day I move to another NG product that doesn't do that. You don't realize the scope of issues that is going to cause. Look at BeOS/Be Inc. if you want to know what lies in store for anyone wanting to play with the big boys.
Certainly no worse than AmigaOS is right now. The x86 solution is quite clear - port to x86, pick a solid board to support early in its life cycle with a long projected life cycle, write drivers and build your new "AmigaXXX" out of it. Integrate emulation for 68k apps in a sandbox. No one cares about PowerPC apps. Buy 1000 boards at $60/each and you have a stock of new "AmigaXXX"s to sell.
There's no advantage to custom hardware, so why use anything but the best? If you look at price/performance/availability/stability on the desktop NOTHING beats x86 quite clearly.
Certainly no less "Amiga" than what is being sold today.
-
Gladly for MIPS: lemote.com/en/products
.
What are the prices of these products?
-
Kremlar,
Come now, the majority of cost of production isn't the creation/assembly so much as licensing. If someone produces an OpenSPARC derived chip and then orders at least 1,000 of them from China, then its gonna be hella cheaper than the current 300 or PA6T orders and then having to deal with licensing costs et cetera.
The Lemote computers are readily available from resellers, they sell them on Amazon and other online retailers. The entire architecture from CPU to firmware is open source, which is good because I've had to deal with the proprietary firmware on servers and coercing them to run BSD instead of RHElL or Windows can be a challenge. Having an open source from top to bottom architecture will help minimize bugs and reduce power consumption, improve ACPI stability etc.
Yes, I'm anti-x86. I'm against a backwards architecture that is poorly engineered, constantly fought over by AMD and Intel, hampered by incompatible addressing modes, uses hacks to extend the opcode possibilities.
A CPU in this day and age doesn't need 1000+ op codes to do its job. And since ABI/API has long since broken legacy software there is little point in conserving the real and protected modes of operations.
You also completely blew off my warning about BeOS: what makes Amiga any different?
Let's see :
Both are niche OS with various open and proprietary solutions
Both suffer from infighting and fragmented user base
Both are hampered by backwards compatibility with the original iteration
Both had official solutions running on PowerPC
Both have open source solutions on x86, neither are very successful outside their niche
BeOS failed permanently when it switched from PowerPC, and dropped it for x86
Sounds an awful lot like history repeats itself.
-
OlafS3,
Tekmote.NL sells some for €200-400, mostly due to import tariffs. If there was more demand I'm sure the cost would drop.
-
Yes, I'm anti-x86. I'm against a backwards architecture that is poorly engineered,.
Big words ...
I would not look down on x86 as this "poor" architecture is a super performer.
x86 also has some big advantages over MIPS and SPARC.
* x86 has good address modes
* x86 can use immediates in instructions directly
This is a big plus
* x86 can directly operate on memory.
Your x86 CPU can with 2 instructions often do about the same work as your MIPS does with 4.
-
The Lemote computers are readily available from resellers, they sell them on Amazon and other online retailers.
I've never heard of them. There's ONE vendor on Amazon named "Revolutionary Books" with a 33% rating (3 reviews in the past 12 months) selling a Lemote netbook for $1500, and also for $2500? This is the architecture you think they should port to?? I seriously doubt you'd ever get one if you ordered from that Amazon vendor.
BeOS failed to right it's ship even after porting to x86 because their sales were atrocious and Apple did not save them. AmigaOS sales are atrocious now, so what's the difference? Hyperion somehow seems to survive by selling a handful of licenses (if that) per month, which Be could not do.
I'm not saying AmigaOS will survive long term by porting to x86, but it certainly won't survive on the path it's on now, and certainly would not survive if ported to ANOTHER obscure platform like you are suggesting.
I'm not a fan of the NG systems in general - I don't see the point, unless something unique can be brought to the table. But, if you're going to do SOMETHING, don't spend incredible resources to just move sideways like you are suggesting.
Amiga was different because it was better. There's nothing better about current NG systems, hardware or software - they are worse. Porting to an obscure platform does not change that. Porting to x86 could at least put them in the ballpark hardware wise, and resources could then be devoted to software instead.
Look what the move to x86 did for the Mac? Saved the platform. Of course the Amiga market doesn't have Apple-like resources, but with WinUAE a sandbox already exists to run classic apps on x86 - and that's half the battle.
AROS isn't successful because:
- It's not "blessed" with the Amiga name
- It tries to support generic x86 hardware and does not have "official" hardware behind it.
- There are not enough resources devoted to it.
Personally, I think the biggest Amiga market is the classic market. A Natami-like product would sell FAR more than a NG product. It's far more interesting.
-
Sure biggun, but it takes longer to have those instructions processed. The small amount of registers, combined with the amount of wasted silicon to useless backwards compatibility, and the overly complicated instruction set is just terrible. It makes a definitely orthogonal architecture like m68k seem RISC by comparison.
It takes about 40 cycles for the average x86/x64 CPU to access memory due to the size of the pipeline, a MIPS R16000 can do it in 11. In addition a benchmark compared a contemporary AMD Phenom to a R16000A, and it found they take about the same amount of time using a single thread to do a task. The AMD edges out as the number of threads increase till you hit the limit of CPUs a single computer can hold, then the R16000A takes the lead again with its ultra fast craylink clustering ability. Craylinked x86 computers are very uncommon whereas the R16000 is deployed with it almost exclusively. The reason why the R16000 can hold out so well has to do with its massive L2 cache in the 1GHz version it is 8MB, and it has a very streamlined instruction set.
Mikhail Kalashnikov, the late designer of the AK47 once said " All that is too complex is unnecessary and it is simple that is needed. " there is much to be said about this in the computing field.
-
It takes about 40 cycles for the average x86/x64 CPU to access memory due to the size of the pipeline, a MIPS R16000 can do it in 11.
??
Where did you get these numbers from?
These are not memory access times.
-
I've never heard of them. There's ONE vendor on Amazon named "Revolutionary Books" with a 33% rating (3 reviews in the past 12 months) selling a Lemote netbook for $1500, and also for $2500? This is the architecture you think they should port to?? I seriously doubt you'd ever get one if you ordered from that Amazon vendor.
BeOS failed to right it's ship even after porting to x86 because their sales were atrocious and Apple did not save them. AmigaOS sales are atrocious now, so what's the difference? Hyperion somehow seems to survive by selling a handful of licenses (if that) per month, which Be could not do.
I'm not saying AmigaOS will survive long term by porting to x86, but it certainly won't survive on the path it's on now, and certainly would not survive if ported to ANOTHER obscure platform like you are suggesting.
I'm not a fan of the NG systems in general - I don't see the point, unless something unique can be brought to the table. But, if you're going to do SOMETHING, don't spend incredible resources to just move sideways like you are suggesting.
Amiga was different because it was better. There's nothing better about current NG systems, hardware or software - they are worse. Porting to an obscure platform does not change that. Porting to x86 could at least put them in the ballpark hardware wise, and resources could then be devoted to software instead.
Look what the move to x86 did for the Mac? Saved the platform. Of course the Amiga market doesn't have Apple-like resources, but with WinUAE a sandbox already exists to run classic apps on x86 - and that's half the battle.
AROS isn't successful because:
- It's not "blessed" with the Amiga name
- It tries to support generic x86 hardware and does not have "official" hardware behind it.
- There are not enough resources devoted to it.
Just an FYI, Amiga and BeOS objectively are two approaches to the same question " How simple can an OS be and still be useful? " neither is objectively better than the other. If you yourself aren't interested in NG Amiga hardware then you're doing nothing more than trolling this topic. Don't put out ideas that will potentially ruin what's left of the community if you have no intention of taking responsibility for your ideas, which your lack of interest clearly indicates.
Furthermore, you don't understand that putting a proprietary OS that lacks most features new users are familiar with on the same ballgame as Windows, OS X and GNU/Linux will result in them being trampled.
The reason the BSD communities are still around are that they mutually assist each other, are ported to several architectures which diversify the risk, and they aren't money driven.
Going after an idea with a gamble such as the entire OS and company at stake is an unacceptable risk, even if the supposed pay off is big. You wouldn't gamble your house in Las Vegas or Cancun Mexico if you had a wife and kids living there was the no second dwelling. As such, the Amiga community is spread too thin for diversifying to work. Instead there needs to be an affordable, high performance niche piece of kit which both NG solutions can agree to support.
There is just too much risk.
-
Sure biggun, but it takes longer to have those instructions processed.
No actually not.
Thats the point.
The same is true of 68k/Phoenix.
Phoenix for example can do this instruction in a single cycle:
ADD.L #$123456,($40,A0,D0*8)
How many instrutions does your typical RiSK need for this?
Exactly what the 68K does in a single Cycle the RISC needs generally 5-6 instructions to do the same.
-
??
Where did you get these numbers from?
These are not memory access times.
Sorry, I phrased that poorly:
To read/write 64 bits of data from or to the main memory:
AMD Phenom: 33-40 cycles on average
MIPS R16000A: 11-15 cycles on average.
I apologise for the confusion.
-
If you yourself aren't interested in NG Amiga hardware then you're doing nothing more than trolling this topic. Don't put out ideas that will potentially ruin what's left of the community if you have no intention of taking responsibility for your ideas, which your lack of interest clearly indicates.
LOL, responsibility for my ideas? If I wanted responsibility for my ideas I'd put my money where my mouth is and fund a project.
I'm not interested in current NG products, but of course if NG becomes more accessible and practical then I may be interested.
Furthermore, you don't understand that putting a proprietary OS that lacks most features new users are familiar with on the same ballgame as Windows, OS X and GNU/Linux will result in them being trampled.
They are being trampled now. The only difference would be the cost of entry would be far lower and future development costs would be less - after, of course, the cost to port to x86.
Be tried to be another x86 operating system. I'm not suggesting that - don't bring your OS to x86. I'm saying pick an inexpensive x86 board and bring it to your OS - more like what Apple did than what Be did.
Going after an idea with a gamble such as the entire OS and company at stake is an unacceptable risk
OK, so why are you suggesting a port to an obscure, obsolete platform?
-
No actually not.
Thats the point.
The same is true of 68k/Phoenix.
Phoenix for example can do this instruction in a single cycle:
ADD.L #$123456,($40,A0,D0*8)
How many instrutions does your typical RiSK need for this?
Exactly what the 68K does in a single Cycle the RISC needs generally 5-6 instructions to do the same.
So? The fact is that while you can feed those into the processor all at once, it takes multiple cycles to do those instructions. The other thing is with larger amounts of registers RISC CPUs can push more data at once. Sure you're correct these instructions have to be done one at a time, but RISC can do those instructions with minimal overhead.
Also let me remind you: memory is cheap now. We don't need a CPU that works direct from memory - working load/store is fine now especially with the norm of NUMA technology and decentralised DMA.
-
So? The fact is that while you can feed those into the processor all at once, it takes multiple cycles to do those instructions.
No.
PHOENIX can do this instrution example in 1 single cycle.
PHOENIX can do every cycle such an instruction.
Also let me remind you: memory is cheap now. We don't need a CPU that works direct from memory - working load/store is fine.
The problem is the instruction throughput.
Lets say you have a super scalar 68K.
Which does just 3 instrutions per cycle.
Do get the same amount of work done you need much much more RISC instructions decoded per cycle.
And this is what kills you. You can not decode 10 instructions per cycle with your RISC chips.
Simply because your Icache is unable to feed so many bytes to you per cycle.
CISC instruction are a form of "compressed" instruction encoding.
This is a big advantage today - as today the cache bandwidth as a limiting factor.
-
BeOS failed on the x86 for the same reason it failed on the PPC, because it had no software legacy... Apple have been able to migrate through two CPU architecture changes and an entire Operating system change, simply because the have a software legacy that people wanted to run and they made sure would run.
Microsoft only survived as a near monopoly for so long only because they had a software legacy, and they stayed compatible with it through their OS architecture changes.
-
LOL, responsibility for my ideas? If I wanted responsibility for my ideas I'd put my money where my mouth is and fund a project.
I'm not interested in current NG products, but of course if NG becomes more accessible and practical then I may be interested.
Then you just supported my point that you're here to troll and nothing more.
They are being trampled now. The only difference would be the cost of entry would be far lower and future development costs would be less - after, of course, the cost to port to x86.
All that needs to be done is increase the cost/performance ratio of the hardware, I have lost faith in POWER considering the cost of an IBM POWER server, and the lack of top of the line designs from POWER6+ and up.
Be tried to be another x86 operating system. I'm not suggesting that - don't bring your OS to x86. I'm saying pick an inexpensive x86 board and bring it to your OS - more like what Apple did than what Be did.
Yeah, because everyone should be like Apple. Bunch of garbage they produce since Leopard. No, just no. That will fail just as hard.
OK, so why are you suggesting a port to an obscure, obsolete platform?
MIPS and SPARC aren't obsolete.
-
I prefer working with an architecture at a low level. The reason I give two %&$#?@!%&$#?@!%&$#?@!%&$#?@!s is because I actually would like to code some for Amiga down the line. Reason I don't now is simple: I am learning 68k assembler and that is one of the most tedious and pedantic languages I've learned because all the current compilers for C are too old and broken for OS 3.9 for me to use. I have been coding on a UNIX style C compiler such as Clang and that's how I intend to do this. GCC is a load of junk though so I may be forced to build my own compiler >_>. Anyways, back to my point: If the Amiga were to become x86 based I'd probably say screw it and not code for it because I have long given up optimising programs on x86 properly. Nothing about the tools I use exposes anything, rather, it is how I treat C as more flexible assembler. I like to be aware of the underlying hardware. With that said I'd probably stick to RISC boxes running BSD or some other UNIX if Amiga moved to x86.
There is a new version of vbcc in the works with much better C99 support. The complete source is available and I compile it with itself on my Amiga (although it can cross compile) along with Frank Wille's vasm and vlink. Only vclib is not publicly available because parts of it use copyrighted code with restrictions (but it's still available for programmers working on vclib). There are no dependencies or too complicated of build tool chains as the original target was embedded systems. It still has sophisticated optimizations (where fully implemented and not buggy) and a working instruction scheduler (for limited targets). It supports simple and easy inline assembler (including many system functions) although it's not as powerful as GCC and CLANG/LLVM assembler inlines (I would like to see support for this but it would be a lot of work). Vasm blows away GAS in ease of use and 68k peephole optimizations. The Amiga support is good and it's easy to install on the Amiga. Before you write your own compiler, maybe you could try it out and consider helping?
http://sun.hasenbraten.de/vbcc/
http://sun.hasenbraten.de/vasm/
http://sun.hasenbraten.de/vlink/
The binaries at the above vbcc link are old. You should e-mail Frank to get the latest sources (my sources may be old). Vbcc does need about 100MB of memory to compile so you would have to either upgrade your Amiga 3000 memory or cross compile. Vasm and vlink can probably be compiled with less than half the memory and the latest sources are available at the links above. You would probably want to install Frank's Posix.Lib for vbcc and my improved C99 68k math libs and support also:
http://aminet.net/dev/c/vbcc_PosixLib.lha http://aminet.net/dev/c/vbcc_PosixLib.lha
http://eab.abime.net/showthread.php?t=74692
The math libs are in 100% 68k assembler by the way. It's almost as easy as a high level language. I wouldn't try that in x86/x86_64 (not much love here from anyone) but your RISC processors wouldn't be much, if any easier. What we really need is a super compact enhanced 68k 32 bit CPU and a new properly designed Super-CISC 64 bit ISA big brother. CISC has real advantages but there hasn't been a new design in years despite the possibility to easily beat the x86_64 in encoding efficiency, code density and ease of programming.
As previously explained I could give a flying freak whether or not it would break binary compatibility. Sure other users care, but I care more about having a 64-bit OS with a CPU that can perform well today.
Don't feed anymore bull, you can look up the dhrystone measurements and other benchmarks yourself, but do keep in mind all of these systems are 64-bit and SMP capable so they're going to beat any slow uniprocessor 32-bit mode OS
64 bit processors can actually be slower in more than a few cases and they are more expensive in terms of resources and therefore cost. They generally do perform better because they are higher end with the expensive and extensive caches needed to make them fast. 64 bit is an advantage for servers and workstations but 90% of Amiga users would be more than happy with a 32 bit 68k Amiga with 300Mips and 1GB of memory.
Please show use where we could buy new Laptops or new Desktop with these for < $500. If you can do this - then your would have a reasonable point.
ARMv8 may be a better future RISC target than PPC, MIPS and SPARC because it's the most likely to have a CPU in portable computers sold to the masses. Performance shouldn't be any more of a limitation than these other RISC processors as the design is not that much different. The first devices may require jail breaking and Android will probably be the logical replacement unless AROS gets an ARMv8 target and is improved very quickly.
-
BeOS failed on the x86 for the same reason it failed on the PPC, because it had no software legacy... Apple have been able to migrate through two CPU architecture changes and an entire Operating system change, simply because the have a software legacy that people wanted to run and they made sure would run.
Microsoft only survived as a near monopoly for so long only because they had a software legacy, and they stayed compatible with it through their OS architecture changes.
Yeah but both drop compatibility relatively quick. Stuff from the 2000/XP era won't always run due to ABI changes, and since its closed, recompiling against the new ABI isn't possible. Likewise with Apple Rosetta is dead. Apple is a status symbol, it is a symbol of eliteness and that's why stupid people buy it. People with brains like me use Android and cheaper alternatives that work just as well.
-
Then you just supported my point that you're here to troll and nothing more.
No, I'm here to discuss a topic on a public message board.
Yeah, because everyone should be like Apple. Bunch of garbage they produce since Leopard. No, just no. That will fail just as hard.
So... Apple produces garbage, and Lemote systems are fantastic? Just trying to set a baseline here.
MIPS and SPARC aren't obsolete.
They are both obsolete and irrelevant on the desktop.
-
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.
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.
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
-
Yeah but both drop compatibility relatively quick. Stuff from the 2000/XP era won't always run due to ABI changes, and since its closed, recompiling against the new ABI isn't possible. Likewise with Apple Rosetta is dead. Apple is a status symbol, it is a symbol of eliteness and that's why stupid people buy it. People with brains like me use Android and cheaper alternatives that work just as well.
Both drop compatibility when developers have caught up with the new architecture. That's simply good business sense.
Apple Rossetta is dead because it doesn't make any sense to keep it going... I don't even have any 32bit x86 Apple apps anymore, let alone any PPC apps.
People buy what they can afford which suits their needs, I'm sure your device suits your needs and fits in your budget, my device does the same. There is no need to be pejorative about anyone's choice.
-
Kremlar, you've worn my patience thin. This is my last response to your post on this thread. You're trolling and I don't appreciate the smart attitude and the high horse approach.
Apple produces expensive rubbish both in hardware and software. Its just an overpriced paperweight running a Mach kernel with proprietary bits and dressed up to look like UNIX. Lemote systems are decent machines, especially from an open hardware perspective. Quality with the first few were lacking but that has somewhat subsided since. I don't care for the main OS that runs on them, but their open nature makes them easily accessible and malleable to various applications.
On the desktop market, SPARC and MIPS are irrelevant, yes, but obsolete? No. There are plenty of chips that would make fine desktop computers. The pieces are out there, it is just up to someone to put them together.
Anyways conversation over. Troll somewhere else, shoo!
-
Both drop compatibility when developers have caught up with the new architecture. That's simply good business sense.
Apple Rossetta is dead because it doesn't make any sense to keep it going... I don't even have any 32bit x86 Apple apps anymore, let alone any PPC apps.
People buy what they can afford which suits their needs, I'm sure your device suits your needs and fits in your budget, my device does the same. There is no need to be pejorative about anyone's choice.
The only reason I give a damn is because their choices influence my range of choices.
I agree that Apple Rosetta has no point, but MS still has people running XP and below! Rather than abruptly cut off the stragglers after a warning or two, they end up weeding them out by hand. It makes no business sense to me, but I don't care for collectivist business approaches anyways.
The fact I can run DOS on a modern x64 laptop is laughably retarded. I still to this day find the addressing modes of x86 making no sense.
-
People buy what they can afford which suits their needs, I'm sure your device suits your needs and fits in your budget, my device does the same. There is no need to be pejorative about anyone's choice.
Right. Different tools for different jobs. My phone runs Android, but I'd recommend an iPhone to most non-technical people.
-
Then you just supported my point that you're here to troll and nothing more.
All that needs to be done is increase the cost/performance ratio of the hardware, I have lost faith in POWER considering the cost of an IBM POWER server, and the lack of top of the line designs from POWER6+ and up.
Yeah, because everyone should be like Apple. Bunch of garbage they produce since Leopard. No, just no. That will fail just as hard.
MIPS and SPARC aren't obsolete.
I am a 68k fan too, a troll how you call it. My main computers are PCs and I also earn my money with them using Windows.
What Kremlar wanted to explain is that NG (AmigaOS and MorphOS and AROS) are only used by a minority of Amiga users right now. I myself use my own distribution based on Aros 68k in UAE, I do not expect it to replace Windows or Linux, it is just fun to play around with it. A new generation of FPGA devices would have that fun and geek factor for many amigans too, none of these devices will beat a modern PC or your workstations by specification but nevertheless it would be fun to use and I am convinced that even people outside the community will buy it.
Regarding SPARC and MIPS, AROS is the only platform that has proven to be portable, if I remember right only one developer ported it in 3 months to ARM in his spare time. So if you want to get something ported to new platforms set up a bounty and convince people to donate, perhaps even some from outside. I can make a bet with you that neither AmigaOS nor MorphOS will ever be ported to MIPS or SPARC.
I see that you very much dislike X86 (or better hate) but as long as you cannot show benchmarks where SPARC or MIPS outperform the big platforms by magnitudes it will be a hard sell. I also told you that it would be expensive (expecially for Hyperion). Regarding Trevor (a-eon) I do think that investing money to make profit is his motivation, he creates his own personal "toys". Profit, market share and so on is certainly not important for him otherwise he would not act like he does. Besides it is a little funny that you are talking about that he should do this or that to sell more because I do not have the impression that you are thinking in economic terms.
And regarding supporting obsolete technologies, that is the difference between someone only being in contact with machines or with the real market. Not long ago one of my customers still used a MS-DOS application. Microsoft supports obsolete technologies not because they are retro but because customers request it otherwise they will not buy new versions of Windows.
-
Apple produces expensive rubbish both in hardware and software. Its just an overpriced paperweight running a Mach kernel with proprietary bits and dressed up to look like UNIX.
My favourite development language is objective-c and I like the power of a 64bit CPU in my mobile devices... Apple gives me both of these things, oh and their OS is a Unix, it's POSIX certified.
-
I didn't call 68k users trolls.
I do realise NG platforms are a minority use. As far as the people using the legacy AmigaOS gp, they're free to do what they want. I've got a 3000, but I don't do much with it.
Anyways, SPARC does pretty well versus Intel, but I don't know enough about hardware to articulate it. I was an electrical engineer in college but quit due to academic issues so I don't know how to exactly compare them properly. The only reason Intel/AMD CPUs are so powerful is the amount of money poured into them. It is like putting a V12 in a Geo Metro. You can do it, but you'd be better off going for system properly designed. A lot more sustainable than modding the hell out of a Geo Metro.
As far as the future of NG Amiga goes I'm unable to participate until that cost/performance ratio goes down, and if I'm not gonna be able to do that on RISC, then I'm going to stick with platforms that show more promise to me on RISC.
CISC just doesn't make sense anymore and there is support for this in the simplicity of RISC. Look at anything else engineering related and you'll see that generally the simpler solution is better.
CISC vs RISC
AR15 vs AK-M
Systemd vs rc init
PlayStation vs Saturn
Gasoline vs Diesel engine
-
My favourite development language is objective-c and I like the power of a 64bit CPU in my mobile devices... Apple gives me both of these things, oh and their OS is a Unix, it's POSIX certified.
I've been over this: Certified UNIX is different from UNIX in the descendant sense.
Kernel is different ( fork of Mach called XNU - X is not UNIX )
Mach is a microkernel developed at CMU, it isn't UNIX which was developed at Bell Labs then forked by Berkeley and AT&T proper as BSD and System V.
NEXTSTEP, Darwin and OSX are POSIX compliant, but not UNIX in the descendant sense. You can dress up Mach all you want but it isn't UNIX.
By this token, AIX, Tru64 and other UNIXes which use fully custom kernels aren't UNIX either in my sense and that is OK in my book.
Objective C is better than C++ and C# but there are some reservations I have about its design.
-
I didn't call 68k users trolls.
I do realise NG platforms are a minority use. As far as the people using the legacy AmigaOS gp, they're free to do what they want. I've got a 3000, but I don't do much with it.
Anyways, SPARC does pretty well versus Intel, but I don't know enough about hardware to articulate it. I was an electrical engineer in college but quit due to academic issues so I don't know how to exactly compare them properly. The only reason Intel/AMD CPUs are so powerful is the amount of money poured into them. It is like putting a V12 in a Geo Metro. You can do it, but you'd be better off going for system properly designed. A lot more sustainable than modding the hell out of a Geo Metro.
As far as the future of NG Amiga goes I'm unable to participate until that cost/performance ratio goes down, and if I'm not gonna be able to do that on RISC, then I'm going to stick with platforms that show more promise to me on RISC.
CISC just doesn't make sense anymore and there is support for this in the simplicity of RISC. Look at anything else engineering related and you'll see that generally the simpler solution is better.
CISC vs RISC
AR15 vs AK-M
Systemd vs rc init
PlayStation vs Saturn
Gasoline vs Diesel engine
As I said Aros is very portable, if you want something on SPARC or MIPS set up a bounty for it and convince people to donate to get it ported. That is the only realistic advice I can give. Or directly contact Trevor D., he is a kind person, perhaps you can convince him to finance the port of AmigaOS (but I have high doubts there). But of course you must offer more than emotions but hard facts and advantages that outweigh the disadvantages of such a change.
And if you do not like AROS and do not want to buy a AmigaOS system you could still buy MorphOS and a used Mac. If none is interesting for you but only AmigaOS ported to SPARC/MIPS it becomes difficult.
And why does CISC make no sense anymore? They are very living and except ARM there is nothing that plays a role at all.
-
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.
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.
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.
-
BSD and IRIX for servers definitely! I'm just saying I like workstations and servers a lot more than portables. I know AmigaOS isn't a server suitable OS. The attitude of the OS 4 devs isn't as bad as some GNU/Linux people. Now you see why I dislike GNU/Linux, in the Arch forums they censor alternative init systems and prevent people from denouncing systemd. That and the Gentoo craze are two reasons I have no trust from GNU and co.
Speaking of ARM though, AMD did announce an Opteron that is ARM based, if it is fast enough I'd support a move to ARM by either NG solution. That would be more my style as AMD already have NUMA clone bus systems and a powerful RISC on that would be badass!
-
CISC just doesn't make sense anymore and there is support for this in the simplicity of RISC. Look at anything else engineering related and you'll see that generally the simpler solution is better.
You repeat marketing slogans of the 90th.
These slogans are technically outdated today.
Some facts:
* CISC has stronger instructions than RISC
In the late 80th and early 90th making a simpler RISC decoders allowed
to invest this into other parts of the chip to improve performance.
As this time RISC chips had a performance advantage.
But technology moved on...
The decode is NOT the bottleneck anymore.
CISC chips can today decode the same amount of instructions as RISC chips.
Today the most complex part and biggest parts of the CPU are the Caches.
Today the main challanges when designing a CPU are:
1) Resolving Instructions dependancies.
CISC has here some advantage - as a CISC CPU an do more with less.
2) Cache access is the other big bottleneck.
CISC has here two big advantages.
* CISC instructions are much more compact. Therefore they can do more with the same ICache Bandwidth.
* The number of possible parallel DCache read and DCache writes
is today the real limiting factor today in CPU design.
As RISC chips lack by design real immediate handling - all RISC chips needs to do more DCache reads to do the same amount of work as CISC chips.
Think about the above technical facts and rethink your opinion about the RISC vs CISC discussion,
-
BeOS failed permanently when it switched from PowerPC, and dropped it for x86
Sounds an awful lot like history repeats itself.
BeOS switched to x86 because it had failed, it didn't fail because it switched to x86. The original BeBox was a PC with a PowerPC instead of an x86, there was no real advantage to them fitting a PowerPC except you had to buy their computer.
History could therefore easily repeat itself. Avoiding x86 will give you a long drawn out death, switching to x86 may or may not pay off but it will play out much quicker.
The only sane decision is between ARM or x86, which is why they own so much of the market between them. The ARM is considerably slower than x86 though, I'd prefer an Atom because it competes pretty well against the ARM but you can also go to the top end with Core I*.
Sorry, I phrased that poorly:
To read/write 64 bits of data from or to the main memory:
AMD Phenom: 33-40 cycles on average
MIPS R16000A: 11-15 cycles on average.
I apologise for the confusion.
That is pretty vague, the R16000A is 200mhz while the Phenom starts at 1.8ghz.
I'd take 40 cycles at 1.8ghz over 15 cycles at 200mhz.
The cycles increase because ram speed lags behind cpu speed, but that is what large caches are for.
If you underclock that Phenom then the average number of cycles would decrease, but it wouldn't get faster.
Your metric is irrelevant.
OlafS3,
Tekmote.NL sells some for €200-400, mostly due to import tariffs. If there was more demand I'm sure the cost would drop.
Where is the demand going to come from? How many people want such a slow computer? The netbooks have appalling battery life.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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/
-
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.