View Single Post
Old 19 June 2017, 23:56   #57
matthey
Banned
 
Join Date: Jan 2010
Location: Kansas
Posts: 1,284
Quote:
Originally Posted by Akira View Post
The problem I expressed in another thread is that the Vampire and Apollo core lands on middle ground between the past and the future Amiga stuff. As such, your first phrase will sadly resonate throughout their whole development.
The Apollo Core ISA creates a standard which is neither backward compatible without the FPU and which only gets us half way into the future and then becomes an impediment to going further. I'll keep my 68060 for the past while I wait for a replacement of the Apollo Core for the future.

Quote:
Originally Posted by Yulquen74 View Post
So, does this mean that the latest and future cores will ignore the mainboard video and sound resources completely, and use its own instead?

If so, why can they not make this a software feature, enabling either one or the other?
Because you are supposed to accept whatever the Apollo Team (Gunnar) decides is best for you. Yea, it should be possible to reboot into a configuration with or without SAGA as the active chipset (select at a boot screen?).

Quote:
Originally Posted by grelbfarlk View Post
Way to miss the point. In case you were unaware the lack of FPU support is not just for compatibility it's for lack of speed as well. Let's just leave this here too:
https://blog.alb42.de/?s=fpu

If you mean that belly aching about applications that could use an FPU being 20x-40x slower than an 060 then that is some terrible belly ache!
Soft float libraries for compilers are usually poorly optimized and very slow. Most ported software comes from the x86 world where they have had fast hardware floating point support for decades. Bottlenecks are created when switching from something very fast to something very slow. I wonder if lantus360 tried compiling an FPU version of OpenBOR and tested several games on his 68040. It doesn't take very much floating point use to make a difference in performance. If the FPU is a bottleneck then it would be possible to see it with OpenBOR. Highly optimized assembler FPU code is not necessary to see the difference caused by lack of FPU hardware and compiler support which could make a moderate difference in thousands of compiled software rather that a big difference in a hand full of assembler titles optimized for a new vectore FPU.

Quote:
Originally Posted by Akira View Post
Unless these programs are rewritten, the advantage they will get from Vampire is minimal.
Holding the Vampire down because of compatibility with hardware 30+ years old is the same mentality Commodore had when making new Amiga models, which didn't really pay off when the machines were released incredibly underpowered compared to current competition. And they were incompatible too and there was much bitching in Amiga world.
This "compatibility" is the reason why you and everyone is here though. It is the common ground which keeps the Amiga community together. Lose a portion of the compatibility and you lose a portion of the Amiga community. I welcome Gunnar to go create a completely new and improved 68k like ISA and make something of it without the Amiga or 68k communities and without any existing software. I didn't see any way to make the 68k the highest performance in the world but I think it could be competitive while maintaining very high compatibility. I do believe the 68k could have the best combination of performance and code density (while maintaining high compatibility) of any 32 bit ISA in the world if that was the focus instead.
matthey is offline  
 
Page generated in 0.05973 seconds with 9 queries