English Amiga Board


Go Back   English Amiga Board > News

 
 
Thread Tools
Old 02 November 2015, 11:50   #81
Samurai_Crow
Total Chaos forever!

Samurai_Crow's Avatar
 
Join Date: Aug 2007
Location: Ft. Collins, CO USA
Age: 43
Posts: 920
Send a message via Yahoo to Samurai_Crow
Quote:
Originally Posted by ppcamiga1 View Post
I do not use asm since 1992.

Proper code in C for amiga compiles without changes on gcc for 68k and ppc.

olaf schoenweiss do not kow this because olaf schoenweiss never use any ppc amiga.
I have a micro a1 and seldom use it. I use FS-UAE more than any Amiga. If software is written for 68k I am more likely to use it. Why? PPC code is 30% bigger and slower per byte and per clock cycle. A 68k clocked at 600 MHz will wipe the floor with the 800 MHz A1. FPGA wins. An improved AGA core in an FPGA will do better yet.
Samurai_Crow is offline  
AdSense AdSense  
Old 02 November 2015, 14:42   #82
Nostromo
Registered User
 
Join Date: Dec 2008
Location: The World!
Posts: 414
If 500 Euro was expensive, I assume this will cost 300?
Nostromo is offline  
Old 02 November 2015, 15:15   #83
Megol
Registered User

Megol's Avatar
 
Join Date: May 2014
Location: inside the emulator
Posts: 254
Quote:
Originally Posted by ppcamiga1 View Post
Because it will be PC. For PC We have windows.
I assume you mean Windows? Not capitalized it doesn't make much sense. :P

But you are incorrect, a PC is a computer with a standardized architecture and have never been exclusively used with Microsoft products. Or even limited to x86 processors - the PReP standard was essentially a PC with a PPC processor and the CHRP was also largely based on the PC standard.
Megol is offline  
Old 02 November 2015, 15:21   #84
Thorham
Computer Nerd

Thorham's Avatar
 
Join Date: Sep 2007
Location: Rotterdam/Netherlands
Age: 41
Posts: 2,972
Quote:
Originally Posted by ppcamiga1 View Post
It is simple - code generated by gcc is too slow to real 68k cpu this means real 68k cpu is crap and need to be replaced with something better.
68k isn't crap, your trolling is crap.
Thorham is offline  
Old 02 November 2015, 15:51   #85
Megol
Registered User

Megol's Avatar
 
Join Date: May 2014
Location: inside the emulator
Posts: 254
Quote:
Originally Posted by Samurai_Crow View Post
I have a micro a1 and seldom use it. I use FS-UAE more than any Amiga. If software is written for 68k I am more likely to use it. Why? PPC code is 30% bigger and slower per byte and per clock cycle. A 68k clocked at 600 MHz will wipe the floor with the 800 MHz A1. FPGA wins. An improved AGA core in an FPGA will do better yet.
But where will we get a 600MHz 68k? The most reasonable way would be buying Stratix 10 chips (claimed to have 1GHz fabric) and hoping one can get a 600MHz processor on that.

But what is the cost of a Stratix 10 FPGA? Probably $7000+ for small quantities.

Or one could take an expensive high-performance Intel chip like a i7 6700K 4GHz (4.2 "turbo", overclockable) ~$400+motherboard+graphics etc.
Assuming one can emulate a 68k at 1/4 the native performance one will get a virtual 1GHz 68k processor...
Megol is offline  
Old 02 November 2015, 17:31   #86
Samurai_Crow
Total Chaos forever!

Samurai_Crow's Avatar
 
Join Date: Aug 2007
Location: Ft. Collins, CO USA
Age: 43
Posts: 920
Send a message via Yahoo to Samurai_Crow
Quote:
Originally Posted by Megol View Post
But where will we get a 600MHz 68k? The most reasonable way would be buying Stratix 10 chips (claimed to have 1GHz fabric) and hoping one can get a 600MHz processor on that.

But what is the cost of a Stratix 10 FPGA? Probably $7000+ for small quantities.

Or one could take an expensive high-performance Intel chip like a i7 6700K 4GHz (4.2 "turbo", overclockable) ~$400+motherboard+graphics etc.
Assuming one can emulate a 68k at 1/4 the native performance one will get a virtual 1GHz 68k processor...
I was thinking more along the lines of a Hard Copy chip. (That's a one-time programmable FPGA.) HardCopy chips of previous generations could clock at 400 MHz or so, so by the time the bugs are worked out of the Apollo core, there may be a newer generation of HardCopy chips that will go faster than a conventional Cyclone 4.

Also, 1/4 native perfomance on an i7 sounds ambitious, especially since each core of an i7 is dual-threaded making the single-threaded speed roughly half that of the core.
Samurai_Crow is offline  
Old 02 November 2015, 20:36   #87
Megol
Registered User

Megol's Avatar
 
Join Date: May 2014
Location: inside the emulator
Posts: 254
AFAIK Hardcopy is a structured ASIC so it should be approximately as expensive as an ASIC.

And you understanding of "Hyperthreading" (the Intel term - marketing garbage) A.K.A. SMT/Simultaneous Multi-Threading is wrong. If one run one thread on a core it will reach 100% of the performance, if one runs two threads one often get 85%+ per thread. SMT is a way to make use of stall cycles, not a way to execute two threads with barrel processing.
Megol is offline  
Old 02 November 2015, 21:44   #88
Samurai_Crow
Total Chaos forever!

Samurai_Crow's Avatar
 
Join Date: Aug 2007
Location: Ft. Collins, CO USA
Age: 43
Posts: 920
Send a message via Yahoo to Samurai_Crow
Ah, well, HardCopy is discontinued as a product anyway. It used to be possible to get a HardCopy chip in smaller quantities without paying as much due to decreased design cost.
Samurai_Crow is offline  
Old 02 November 2015, 22:23   #89
prowler
Global Moderator

prowler's Avatar
 
Join Date: Aug 2008
Location: Sidcup, England
Posts: 10,280
A quick look at ppcamiga1's posts confirms that his main focus is indeed trolling.
prowler is offline  
Old 02 November 2015, 22:56   #90
Mr.Flibble
Registered User

Mr.Flibble's Avatar
 
Join Date: Jun 2015
Location: UK
Posts: 360
Ah, you got to play with Mjölnir for a bit
Mr.Flibble is offline  
Old 03 November 2015, 15:49   #91
Megol
Registered User

Megol's Avatar
 
Join Date: May 2014
Location: inside the emulator
Posts: 254
Quote:
Originally Posted by Samurai_Crow View Post
Ah, well, HardCopy is discontinued as a product anyway. It used to be possible to get a HardCopy chip in smaller quantities without paying as much due to decreased design cost.
One less option :/

Perhaps eASIC could be an alternative? Don't know how easy it is to port from Altera. http://www.easic.com/
Megol is offline  
Old 03 November 2015, 16:13   #92
iggybeans
Registered User

 
Join Date: Oct 2015
Location: Bear Delaware, USA
Age: 56
Posts: 37
Quote:
Originally Posted by Samurai_Crow View Post
I have a micro a1 and seldom use it. I use FS-UAE more than any Amiga. If software is written for 68k I am more likely to use it. Why? PPC code is 30% bigger and slower per byte and per clock cycle. A 68k clocked at 600 MHz will wipe the floor with the 800 MHz A1. FPGA wins. An improved AGA core in an FPGA will do better yet.
I can't imagine the cost of building an FPGA system that could clock an Amiga core to 600MHz (but the highest end FPGA models might be able to do that).
iggybeans is offline  
Old 03 November 2015, 16:17   #93
iggybeans
Registered User

 
Join Date: Oct 2015
Location: Bear Delaware, USA
Age: 56
Posts: 37
Quote:
Originally Posted by Thorham View Post
68k isn't crap, your trolling is crap.
Yes, I found that offensive too.
When IBM settled for using CPUs from a company that was primarily focused on making calculator processors, Motorola was already way ahead of Intel.
And the 68K maintained that lead for years.
iggybeans is offline  
Old 03 November 2015, 20:44   #94
Megol
Registered User

Megol's Avatar
 
Join Date: May 2014
Location: inside the emulator
Posts: 254
Quote:
Originally Posted by iggybeans View Post
Yes, I found that offensive too.
When IBM settled for using CPUs from a company that was primarily focused on making calculator processors, Motorola was already way ahead of Intel.
And the 68K maintained that lead for years.
I guessing that you are referring to Intel? If so you should brush up on microprocessor history. Calculator processors? LOL!
Megol is offline  
Old 03 November 2015, 20:54   #95
iggybeans
Registered User

 
Join Date: Oct 2015
Location: Bear Delaware, USA
Age: 56
Posts: 37
Quote:
Originally Posted by Megol View Post
I guessing that you are referring to Intel? If so you should brush up on microprocessor history. Calculator processors? LOL!
Brush up? I'm old enough to remember it.
That was what TI and Intel initially produced.
And IBMs choice of the 8088 was particularly pathetic for a costly machine.
That gave the system an 8 bit data path to memory, whereas the 8086 at only slightly more cost would have given a 16 bit data path to memory.

Don't presume to lecture me about microprocessors, I was using computers before the microprocessor existed.
My first personal computer was a hand built SWTPC system, and in the '80s and '90s I worked for a company that designed and built 68K based multitasking multiuser systems.

In laughing out loud, you are only making a fool of yourself.
And I have no time for fools.
iggybeans is offline  
Old 04 November 2015, 14:01   #96
Samurai_Crow
Total Chaos forever!

Samurai_Crow's Avatar
 
Join Date: Aug 2007
Location: Ft. Collins, CO USA
Age: 43
Posts: 920
Send a message via Yahoo to Samurai_Crow
Quote:
Originally Posted by Megol View Post
One less option :/

Perhaps eASIC could be an alternative? Don't know how easy it is to port from Altera. http://www.easic.com/
Maybe so. The current Apollo Team softcore is written in VHDL though the consumer-grade Altera Cyclone 4 FPGAs will only clock the core up to roughly 133 MHz. (At least that's enough to outrun a 68060 by a long shot bringing feasibility to future development.)

Beating an ASIC with an FPGA is difficult. I estimated that a 500-600 MHz core based on 68k would be enough to wipe the floor with my PPC 750FX at 800 MHz due to RISC core inefficiency associated with the Load/Store architecture. Since the PPC doesn't use opcode fusion like the Apollo core, the FPGA might catch up with lower clock speeds than even 400 MHz!

Using a modular eASIC-style ASIC could get the speed up to what we need if the demand is high enough. Some obstacles are that the core has to be debugged first. Also, since the Apollo core drops some 68k functions that are not legal to use on the Amiga chipset systems, the chip would need to be an SoC with its AGA++ core integrated to make the expense worthwhile of doing the die layout. (The reason I think that is the case is because the Apollo core is only user-mode ISA compatible with 68k. There are other 68k systems that it won't work with.)

IF that all happens, it'll be interesting to see how it stacks up against the PPC and more importantly, how well the AGA++ core can mop the floor with an older Radeon card. My MicroA1 has a Radeon 7000 chip on the motherboard and it isn't upgradable. (If the AGA++ graphics core can go far enough to compete with my sister's old Radeon X700, I'll probably ditch PPC for good! The PPC already can't keep up with my Core2 Duo-based Mac.)
Samurai_Crow is offline  
Old 04 November 2015, 15:56   #97
Megol
Registered User

Megol's Avatar
 
Join Date: May 2014
Location: inside the emulator
Posts: 254
Quote:
Originally Posted by iggybeans View Post
Brush up? I'm old enough to remember it.
That was what TI and Intel initially produced.
When the 8086 was released (IIRC 1 1/2 years before the 68000) it was the fourth generation of general purpose processors from Intel. The 6th generation counting the microcontroller family (4004 and 4040).

The 8008*, the 8080 and the 8085 preceded it. They were all general purpose and all generally not used for calculators. At this time there were already specialized calculator chips available that cost less and consumed less power.

(* it's probably this one you call a calculator processor however it was designed originally as a terminal controller)

Quote:
And IBMs choice of the 8088 was particularly pathetic for a costly machine.
That gave the system an 8 bit data path to memory, whereas the 8086 at only slightly more cost would have given a 16 bit data path to memory.
It also made the system cheaper as it could use 8bit components and 8 bit memory (actually 9 bit due to parity) and thus lower component count (even with the 8086/8088 bus multiplexing).

The 68000 in comparison was used for high-end expensive computers as it was considerably more expensive in every way.

Quote:
Don't presume to lecture me about microprocessors, I was using computers before the microprocessor existed.
My first personal computer was a hand built SWTPC system, and in the '80s and '90s I worked for a company that designed and built 68K based multitasking multiuser systems.

In laughing out loud, you are only making a fool of yourself.
And I have no time for fools.
If one would call Intel something based on what they were originally known for then Intel is/was a memory company - as it was the product line that got it started. They never was known for making calculator chips.

I found the idea of Intel being called a calculator processor manufacturer funny, is that enough to make me a fool? Well then I'm a fool!

LOL!
Megol is offline  
Old 04 November 2015, 18:49   #98
iggybeans
Registered User

 
Join Date: Oct 2015
Location: Bear Delaware, USA
Age: 56
Posts: 37
Quote:
Originally Posted by Megol View Post

I found the idea of Intel being called a calculator processor manufacturer funny, is that enough to make me a fool? Well then I'm a fool!

LOL!
Sorry, that WAS overboard, and I have my foolish moments too.
And yes, I was specifically thinking of the 4004 (which the 8088 IS descended from).
So referring to them as calculator processors isn't that far off base.

And what really bugged me was the marketing of these as full 16 bit processors when they are 8/16 bit processors.
Also at 4.77 MHz the 8088 is outperformed by a 6809 of less than half its speed (if we want to compare processors from the same era).

So no, I wasn't really happy with Intel until the '386 was introduced.
It finally had the features needed to port some on the software that I was already using on Motorola processors.

Of course today's X64 processors bear little resemblance to their progenitors, so I'm not one of the "let's just build a really fast 68K" fanatics.

Although, I still mix in AMD processors whenever they will suffice (its always nice to support the underdog).

AND my primary Blender/CAD machine is Intel based (dual Xeon).
iggybeans is offline  
Old 04 November 2015, 20:48   #99
matthey
Banned
 
Join Date: Jan 2010
Location: Kansas
Posts: 1,284
Quote:
Originally Posted by Samurai_Crow View Post
Beating an ASIC with an FPGA is difficult. I estimated that a 500-600 MHz core based on 68k would be enough to wipe the floor with my PPC 750FX at 800 MHz due to RISC core inefficiency associated with the Load/Store architecture. Since the PPC doesn't use opcode fusion like the Apollo core, the FPGA might catch up with lower clock speeds than even 400 MHz!
I agree that the Apollo core is potentially much stronger at single core integer performance than most old and low end RISC processors but how much is difficult to estimate.

1) Is the Apollo core in an FPGA or in a real ASIC?
2) Does the Apollo core have a good compiler and instruction scheduler?
3) What kind of caches and memory are used?
4) What kind of algorithms are used?

I believe an FPGA Apollo core could outperform, at the same clock speed, most Thumb 2 ARM processors (where power efficiency is more important than performance) in single core performance. PPC is generally stronger but ARM has been closing the gap with deeper pipelines, OoO and recently a new ISA. The G3 PPC processors are old, simple and power efficient shallow pipeline designs (limits clock speed) but do have some advanced features like reservation stations and large caches (needed for PPC performance). The Apollo core in FPGA could retire more integer instructions per cycle, would be considerably faster per cycle at multiply and would not suffer from RISC load/store bubbles but a good compiler with instruction scheduler is still imperative to take advantage of the 3 integer units and 3 op code fusion without OoO.

Quote:
Originally Posted by Samurai_Crow View Post
Using a modular eASIC-style ASIC could get the speed up to what we need if the demand is high enough. Some obstacles are that the core has to be debugged first. Also, since the Apollo core drops some 68k functions that are not legal to use on the Amiga chipset systems, the chip would need to be an SoC with its AGA++ core integrated to make the expense worthwhile of doing the die layout. (The reason I think that is the case is because the Apollo core is only user-mode ISA compatible with 68k. There are other 68k systems that it won't work with.)
Some of the pseudo ASICs are affordable in small unit quantities but it is not clear how much of a performance advantage there would be. I have my doubts after reading up on some of them. A real ASIC Apollo/Amiga SoC is probably the way to go if it could be afforded but (one time) NRE costs would likely be $250,000-$1,000,000. This would probably require production of 10,000 to 100,000 units per year to make the per unit costs affordable and pay for the NRE costs in a reasonable amount of time. This is why I approached embedded companies for non-Amiga use sharing.

Quote:
Originally Posted by Samurai_Crow View Post
IF that all happens, it'll be interesting to see how it stacks up against the PPC and more importantly, how well the AGA++ core can mop the floor with an older Radeon card. My MicroA1 has a Radeon 7000 chip on the motherboard and it isn't upgradable. (If the AGA++ graphics core can go far enough to compete with my sister's old Radeon X700, I'll probably ditch PPC for good! The PPC already can't keep up with my Core2 Duo-based Mac.)
Amiga FPGA graphics "mop the floor" compared to real AGA graphics but I doubt Amiga ASIC graphics would be much, if any, faster than your older Radeon graphics card. An Amiga ASIC production process would be older to hold the cost down and the Amiga technology is not optimized for high speeds. However, 2D performance has reached the point of diminishing returns and gains are barely noticeable. An Amiga 3D design would need to be developed or bought with either likely many years behind new commodity graphics cards. There would be a small advantage of using integrated graphics and graphics memory without going through a bus.

Last edited by matthey; 04 November 2015 at 20:53.
matthey is offline  
Old 05 November 2015, 12:33   #100
OlafSch
Registered User
 
Join Date: Nov 2011
Location: Nuernberg
Posts: 456
Quote:
Originally Posted by matthey View Post
I agree that the Apollo core is potentially much stronger at single core integer performance than most old and low end RISC processors but how much is difficult to estimate.

1) Is the Apollo core in an FPGA or in a real ASIC?
2) Does the Apollo core have a good compiler and instruction scheduler?
3) What kind of caches and memory are used?
4) What kind of algorithms are used?

I believe an FPGA Apollo core could outperform, at the same clock speed, most Thumb 2 ARM processors (where power efficiency is more important than performance) in single core performance. PPC is generally stronger but ARM has been closing the gap with deeper pipelines, OoO and recently a new ISA. The G3 PPC processors are old, simple and power efficient shallow pipeline designs (limits clock speed) but do have some advanced features like reservation stations and large caches (needed for PPC performance). The Apollo core in FPGA could retire more integer instructions per cycle, would be considerably faster per cycle at multiply and would not suffer from RISC load/store bubbles but a good compiler with instruction scheduler is still imperative to take advantage of the 3 integer units and 3 op code fusion without OoO.



Some of the pseudo ASICs are affordable in small unit quantities but it is not clear how much of a performance advantage there would be. I have my doubts after reading up on some of them. A real ASIC Apollo/Amiga SoC is probably the way to go if it could be afforded but (one time) NRE costs would likely be $250,000-$1,000,000. This would probably require production of 10,000 to 100,000 units per year to make the per unit costs affordable and pay for the NRE costs in a reasonable amount of time. This is why I approached embedded companies for non-Amiga use sharing.



Amiga FPGA graphics "mop the floor" compared to real AGA graphics but I doubt Amiga ASIC graphics would be much, if any, faster than your older Radeon graphics card. An Amiga ASIC production process would be older to hold the cost down and the Amiga technology is not optimized for high speeds. However, 2D performance has reached the point of diminishing returns and gains are barely noticeable. An Amiga 3D design would need to be developed or bought with either likely many years behind new commodity graphics cards. There would be a small advantage of using integrated graphics and graphics memory without going through a bus.
Trying to compete with modern graphic cards in 3D area is a crazy idea. Perhaps offering some low level routines in FPGA so that 3D games could be optimized a little but more does not make sense. 68k needs as much as possible horsepower and RAM. The strength of Amiga was 2D gaming so there should be the focus, trying to compete with PCs today in 3D area makes no sense.
OlafSch is offline  
AdSense AdSense  
 


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools

Similar Threads
Thread Thread Starter Forum Replies Last Post
"Reminder "Lincs Amiga User Group aka "LAG" Meet Sat 5th of January 2013" rockape News 4 30 January 2013 01:06
CD32 Image-Name-Bug: "...(bla)[!].zip" -> "...(bla)[" / "...[test].zip" -> "...[tes" cfTrio support.WinUAE 8 18 December 2012 17:31
Modded cs-ppc , socketed oscillators on small "pcb" keropi Hardware pics 9 26 March 2007 16:21
PPC-Hardware: "Samantha" with PPC440 and ATI-onboard graphic? Paul News 3 09 September 2006 21:17
Problems with "Thespywholovedme", "Flood", "Shinobi" sareks support.Games 12 03 May 2006 15:52

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +2. The time now is 05:01.


Powered by vBulletin® Version 3.8.8 Beta 1
Copyright ©2000 - 2017, vBulletin Solutions, Inc.
Page generated in 0.47223 seconds with 11 queries