Overview Features Coding ApolloOS Performance Forum Downloads Products Order Contact

Welcome to the Apollo Forum

This forum is for people interested in the APOLLO CPU.
Please read the forum usage manual.
Please visit our Apollo-Discord Server for support.



All TopicsNewsPerformanceGamesDemosApolloVampireAROSWorkbenchATARIReleases
Documentation about the Vampire hardware

AGA Vs FPUpage  1 2 

Marcus Sackrow

Posts 37
30 Jun 2017 08:25



Who decide what will be in the next core of Vampire? Its certainly not Gunnar as long he claims to have nothing to do with Vampire cards at all, so who decide that?

Because I want to throw my opinion to the market:

Leave away AGA and Pamela and such stuff, but put the FPU into. I'm not a gamer and for AGA things I have a A1200, Sounds are good enough for my ears and if not, then I buy soundcard for clock port.

I like to have fast RTG and fast CPU and fast FPU, the fastest Amiga ever seen.

I know I'm a minority with this opinion, but please don't kill me just because I tell it ;)
I know many people are very excited about that AGA/Pamela stuff, I'm not. I see for a standalone Version it is needed but for me it's just useless.

Maybe there are more people with this opinion and the creators consider the possibility to make a special core version for people not interested in AGA/Pamela but interested in FPU.




Gunnar von Boehn
(Apollo Team Member)
Posts 6207
30 Jun 2017 08:35


Marcus Sackrow wrote:

   
Who decide what will be in the next core of Vampire? Its certainly not Gunnar as long he claims to have nothing to do with Vampire cards at all, so who decide that?

Your post misquotes me.
I said I did not design the V1 and V2.

Marcus Sackrow wrote:

Because I want to throw my opinion to the market:
   
Leave away AGA and Pamela and such stuff, but put the FPU into. I'm not a gamer and for AGA things I have a A1200, Sounds are good enough for my ears and if not, then I buy soundcard for clock port.
   
I like to have fast RTG and fast CPU and fast FPU, the fastest Amiga ever seen.
   
I know I'm a minority with this opinion, but please don't kill me just because I tell it ;)
  I know many people are very excited about that AGA/Pamela stuff, I'm not. I see for a standalone Version it is needed but for me it's just useless.
   
Maybe there are more people with this opinion and the creators consider the possibility to make a special core version for people not interested in AGA/Pamela but interested in FPU.

 
Please don't think hardware development could be done just quickly.
Assuming this would be naive.
 
This is not a Disco here - were the DJ can change the Record to play in seconds.
   
In the hardware development, work items take a lot time to be done. Many month of time.
Also tasks like "just" size tweaking on a core unit can take several month of time.
   
   
Imagine I'm Gunnar the Viking chieftain, and you are in a boat with me. And we are rowing since 3 month into direction America, to discover this new country, and on the horizon you can already see the coast.
Now you stand up and say "Guy lets turn around, I prefer to go to Australia" - What would the Vikings now do?

Once the course is set - you finish what you started.


Marcus Sackrow

Posts 37
30 Jun 2017 08:47


Gunnar von Boehn wrote:

  This post sound a little bit naive.

  Imagine I'm Gunnar the Viking chieftain, and you are in a boat with me.
  And we are rowing since 3 month into direction America, to discover this new country, and on the horizon you can already see the coast.
  Now you stand up and say "Guy lets turn around, I prefer to go to Australia" - What would the Vikings now do?

Yeah maybe,

but do you prefer to know that 3 month after leaving europe or 12 month after you arrived in America and finally notice the people do not wanted to go there?

Nobody asks for a direction change but maybe a branch? As you stated numerous times the FPU is there and working and lightning fast.

As I said, it's my opinion.



Mr Niding

Posts 459
30 Jun 2017 08:55


Since you have posted in Jaris SoftFPU thread, I realise you are aware of the status there, but Im just going to reitiate that aspect;

Apollo Team has spent alot of time on the direction they CURRENTLY are heading, and the concern of the FPU is being covered by another developer, outside the team.
Basically an additional resource/developer has entered the scene, which offloads workload/distraction for the Apollo Team.

As Jari says himself; he has just started touching upon SoftFPU, and given his quick progress, I think there is alot of potential on the short term.
I for one is very excited about Pamela, since I always listen to music when using my computer(s).

People want to go there, espesially when they are provided with both destinations at the same time.


Gunnar von Boehn
(Apollo Team Member)
Posts 6207
30 Jun 2017 08:57


Marcus Sackrow wrote:

Nobody asks for a direction change but maybe a branch?

 
You have no experience in hardware do you?
 
Hardware is not dne 2minutes like MAKE, MAKE INSTALL.
Hardware means "Adaption" to the used FPGA - this takes month.
If the FPU did use MLAPS but the compile target does not have them then you need to re-design this part.
If the FPU was based on timing behavior of a 6 input ALM but the target FPGA has 4 input LEs than you need to re-balance the muxes to keep the timing.
 
Timing on an FPGA is a like a balanced tree.
The longest tree branch defines the end timing.
If you "move" such a tree from on place into another chip, or another space in the same FPGA, then this does affect it.
To correct this you will need to re-balance the whole tree.
 

Marcus Sackrow wrote:

As you stated numerous times the FPU is there and working and lightning fast.
As I said, it's my opinion.

 
The FPU is there. its working, and functional.
It was designed for Stratix and it does some month work to adapt in placement to the FPGA used on the Vampire2 to run optimally.
 
The FPU is super scalar and fully pipelined.
So from design 10 times more advanced than 68060 FPU.
But there is NO software in AMIGA world existing at the moment
which is designed to make use of a pipelined FPU, and super scalar FPU.


Marcus Sackrow

Posts 37
30 Jun 2017 09:33


Gunnar von Boehn wrote:
 
  You have no experience in hardware do you?

Enough to know how it basically work, usually I only have to use them (other developers writes the code for it) but of course they explain me what is possible or not. And I know basically how Verilog and VHDL (which looks very close to Pascal :-P) work. (But we go for Xlinix ;))
I know that it is painful to change the FPGA (or even the IDE version *g*).

Gunnar von Boehn wrote:
 
  But there is NO software in AMIGA world existing at the moment
  which is designed to make use of a pipelined FPU, and super scalar FPU.

There is no software for hardware that does not exists? Wow, what a news.
And this will for sure not change until it is available. Even there is not pipelined FPU optimized Code out there.. there are a lot of programs benefit from a fast FPU... take MUIMapparium (surprise! :-D)




Gunnar von Boehn
(Apollo Team Member)
Posts 6207
30 Jun 2017 09:41


Marcus Sackrow wrote:

There is no software for hardware that does not exists?
Wow, what a news.

And this will for sure not change until it is available.

Maybe this will never change?

Lets state some fact:

Adapting the FPU to "fit" in the VAMPIRE2 cost "me" some month worktime.

These month of time could also be used to test AGA.

Or to bring out the Vampire-1200

So its a priority decision to make.

Some month ago we wrote this clearly here.
We clearly said putting some month work in the FPU makes much more sense if some coders are also willing to create software using the Super-Scalar Design.

We invited people to write some ASM code creating some "usecases" for AMIGA. No people did anything.




Marcus Sackrow

Posts 37
30 Jun 2017 09:47


Gunnar von Boehn wrote:

 
  Maybe this will never change?
 

  For sure!
 
 
Gunnar von Boehn wrote:

  Lets state some fact:
 
  Adapting the FPU to "fit" in the VAMPIRE2 cost "me" some month worktime.
 
  These month of time could also be used to test AGA.
 
  Or to bring out the Vampire-1200
 
  So its a priority decision to make.
 

 
  Exactly! finally you got my opinion... I just want to state _my_ opinion! that the you/the team should move towards FPU and not AGA and such stuff. And I wanted to state that even I know I'm maybe a minority in the community. Maybe there are more people out there thinking like me and your priority change, even my hopes on that is very small :P, but I tried.
 


Montag PS

Posts 8
30 Jun 2017 09:49


I'm sorry but I don't understand this attitude.
  You already said that you would prefer a fast CPU+FPU instead of some extra features (I suppose on the Vampire, since it's the only board at the moment that supports the Apollo core). And you got an answer that's basically "Sorry, but at the moment, with this physical hardware, we are not going there".
  Everyone in this forum would simply love to have the most advanced Amiga hardware, and a fast FPU is certainly part of that dream machine, but we will get it at a later time, in some form or another (SoftFPU? new FPGA?). Let's sit down for now and see what happens next.
  We waited for decades to come to this point, so a couple of months/years more shouldn't make much of a difference, no? :)

EDIT: Wow, you are fast typers! This was actually a reply to a previous post :D


Gunnar von Boehn
(Apollo Team Member)
Posts 6207
30 Jun 2017 09:54


Marcus Sackrow wrote:

that the you/the team should move towards FPU and not AGA and such stuff. 

You could have influenced this.
But not by posting your wishes or opinions here.

But by DOING something!

If you would have stepped up and said:
I want to help and I will write Super-Scalar-FPU Killer app then this would have clearly influenced this.




Saladriel Amrael

Posts 166
30 Jun 2017 09:55


I think it's clear, I'm going to resume, just to use different words to explain this and lessen the communication issues:

Apollo FPU is existing and working, altough on a different HW and configuration than the one used in Vampire. let's remember Apollo and Vampire are NOT the same thing: Vampire uses a particular configuration of Apollo core running on a given FPGA hardware.
Now, this FPGA hardware and configuration are quite different from the one where the FPU is running, so in order to put the FPU into the Vampire a lot of work is required.

I think it's also clear that the goal of Apollo and Vampire teams is to have a board that will, at last, give us (or at least try to do the best to) a full compatible OCS/ECS/AGA + 68k + FPU + SAGA (Where both CPU and FPU are going to be updated with modern design concepts).

But, being time and resources humanly limited both teams are going to make choices about which compartment give priority to, and about now they are prioritizing AGA/SAGA/Paula/Pamela integration, and I can see why:
1) There are more (by sheer numbers) softwares demanding AGA/Audio than softwares demanding FPU
2) Having AGA/Paula fully implemented means open doors for Stand Alone model (I believe, correct me if wrong)
3) Despite of that, seeing how strong the requestes for FPU were, they opened up doors for active collaboration by users, but nobody stepped in.

That's what I understood by reading the threads in these weeks, and if everything is correct, I fully understand and morally support the choices of the teams.




Jan Vonka

Posts 60
30 Jun 2017 10:45


Marcus Sackrow wrote:
Leave away AGA and Pamela and such stuff, but put the FPU into. I'm not a gamer and for AGA things I have a A1200

Implementing AGA into the FPGA is an excellent idea and one of many advantages is also to have finally ONE monitor connected to Amiga where all planar and chunky goes to one hdmi output (in this case three when I include sound).

Marcus Sackrow wrote:
Sounds are good enough for my ears and if not, then I buy soundcard for clock port.

Gimme a break clockport sound cards are so rare and crazy expensive so when you are lucky and get one you pay at least the same money as for entire Vampire card.

Marcus Sackrow wrote:
I know many people are very excited about that AGA/Pamela stuff, I'm not. I see for a standalone Version it is needed but for me it's just useless.
 
Maybe there are more people with this opinion and the creators consider the possibility to make a special core version for people not interested in AGA/Pamela but interested in FPU.

Guys PLEASE leave the development approach up to Apollo core team. Support them with software development, testing, reporting, but DAMANDING to prioritize something based on your wishes and asking them to leave current development is ridiculous and Gunnar then wastes time answering you.

If you check FPU thread there is already SoftFPU in progress, hopefully this will satisfy you soon.


Marcus Sackrow

Posts 37
30 Jun 2017 10:52


Gunnar von Boehn wrote:
 
  But by DOING something!

I have a lot of FPU stuff, take MUIMapparium or the Kraft physics engine (which i only use not write myself), I have more things on my harddisk, BUT:

Gunnar von Boehn wrote:
 
  If you would have stepped up and said:
  I want to help and I will write Super-Scalar-FPU Killer app then this would have clearly influenced this.

It will not gonna happen, as long it goes to write incompatible stuff (like Assembler, or even worse, something like RiVA), it would go against everything I always work for and everything I stand for. I'm clearly a cross platform coder, my aim is and was to make cross Amiga source codes, there I put all my work into (it was a lot of work to bring FPC to a level where you really can write one Source and compile/run them on EVERY Amiga style platform)
And on the Integer level Vampire does already a great job, some NG aimed programs work already nicely without further quirks. But on the FPU it's stuck on the 80s.



Olaf Schoenweiss

Posts 690
30 Jun 2017 11:13


how do you know that people do not want to go to america?

in practical terms AGA including better sound is more important for many people than FPU

it was repeated countless times that FPU is on to-do-list but it is a matter of limited resources and priority and BTW it is not your project


Olaf Schoenweiss

Posts 690
30 Jun 2017 11:15


what if I would say that I and Niding vote for AGA and not FPU

2:1

and now what?

People...


Gunnar von Boehn
(Apollo Team Member)
Posts 6207
30 Jun 2017 11:20


Marcus Sackrow wrote:

It will not gonna happen, as long it goes to write incompatible stuff (like Assembler)

 
Did I understand this right?

You ask me to "put" the FPU in the Vampire2.
This is a size tweaking just which takes creates for me several month of work, you have no problem asking for this.

You are a coder, when you are asked if you would help write a ASM FPU app, then writing in ASM is below your pride?
 

Lets get this straight:
 
1) Developing a Super Scalar Pipelined FPU is already a MIRACLE.
And a mountain of work.
 
2) So the first thing you do is "You use it, in ASM"
and after you understood it, learned it, and also improved from what was learned -
 
3) then you go to the next mountain of work to make compiler support to leverage it fully.
 
 
This is the natural order in which such developments are ALWAYS done.
 
 
You do not want to help here. OK fine.


Olaf Schoenweiss

Posts 690
30 Jun 2017 11:29


I think many people would be happy if there would be some compatible FPU even if it would be not that much faster than on 68060/50. Of course some would even than moan again...

The basic problem is to add the new super-features of the core to the compilers because not everyone is willing or able to write hand-coded assembler


Chain Q

Posts 19
30 Jun 2017 12:13


OK, I try to be really constructive here, and not call out on the BS...

The Apollo Team talks about a full fledged superpipelined FPU, vs. a full software implementation, because the former is "hard".

Well. It's quite well known, that real world software for the FPU is mainly written in high level languages, and most - especially the recent - compiler implementations really only use a tiny subset of the FPU's capabilities. But this was already the case back in the days, hence why Motorola opted for a partial FPU implementation in the more advanced chips, and then striped the spec even further down for the CFv4e FPU. I know I'm Captain Obvious here, but anyway.

So the bottom line is, instead of mountains of work, how about talking about something minimal but very useful instead. How about the hardware trying to support the software implementation instead. I'd say a software FPU implementation needs the followings to be fast (or along these lines):

A., an as fast trap mechanism as possible, maybe a special partial trap for the FPSP routines (avoiding integer register flush/restore somehow?). Or the core could do the instruction decoding and already present the operands somehow and call the right routine, instead of the software having to do the full instruction decoding after the trap? Just brainstorming here.
B., an internal register set for the CPU, so values don't have to be saved/restored all the time when an FPU instruction is executed. maybe just some kind of internal SRAM, which is faster to access, anything counts. We're talking about ~100 byte storage space here...
C., a partial FMOVE, (maybe partial FMOVEM for fast function entry/exit), FADD/FSUB, FMUL in full extended precision. Maybe rounding to double/single precision by hardware (as a separate operation). This could actually be implemented step-by-step, to replace software calls one by one.
D., an FPSR register, to show the result of the last operation.

Everything is more or less doable in software, large parts of it are done by software on the '060 anyway. Exceptions, the dozen data formats, bla bla bla, software only, nobody cares.

And if you want software written for floating point - I've already seen OWB running on AROS/68k. Everything in Javascript is floating point, by definition. Hence everything on the web is floating point. Do I really need to say more?

You just get a Javascript compiler testsuite, compile it with GCC, and analyze it for the most used instructions. Then try to make the hardware support or at least assist those somehow.


Gunnar von Boehn
(Apollo Team Member)
Posts 6207
30 Jun 2017 13:09


Chain Q wrote:

A., an as fast trap mechanism as possible, maybe a special partial trap for the FPSP routines (avoiding integer register flush/restore somehow?). Or the core could do the instruction decoding and already present the operands somehow and call the right routine, instead of the software having to do the full instruction decoding after the trap? Just brainstorming here.
  B., an internal register set for the CPU, so values don't have to be saved/restored all the time when an FPU instruction is executed. maybe just some kind of internal SRAM, which is faster to access, anything counts. We're talking about ~100 byte storage space here...
  C., a partial FMOVE, (maybe partial FMOVEM for fast function entry/exit), FADD/FSUB, FMUL in full extended precision. Maybe rounding to double/single precision by hardware (as a separate operation). This could actually be implemented step-by-step, to replace software calls one by one.
  D., an FPSR register, to show the result of the last operation.

We think 100% the same way.
And this is exactly how we are doing the SOFTFPU


David Wright

Posts 373
30 Jun 2017 13:38


Throw Marcus out of the boat Gunnar.

posts 37page  1 2