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
Information about the Apollo CPU and FPU.

GCC Improvement for 68080page  1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 

Gunnar von Boehn
(Apollo Team Member)
Posts 6207
04 Aug 2019 09:28


Stefan "Bebbo" Franke wrote:

 
Gunnar von Boehn wrote:

   
Stefan "Bebbo" Franke wrote:

      Question:
       
      Is there a case where double indirect is useful?
     

     
      "Useful" might depend on viewpoint.
     
      "Needed" is much easier to answer: Its clearly not needed.
     
      You can always get the same result using 2 instructions.
      Double indirect is slow. Its not faster than doing 2 instruction.
      Double indirect increases instruction length.
      Its often the same size as using 2 instructions.
      Double indirect uses an "internal" TMP-Address register - so you not
      need an architectural register for this.
    [/cost]
   

    so it saves a register and is not slower
 
 
 
 
The Double-Indirect mode does 2 memory access which are depending. 
These means that this operation is pessimal depending.
 
 
Why is this a bad idea?
The operation by design exposes the pipeline length of the CPU.
This means this operation will get slower as more pipelined/faster /higher clocked the CPU is.
This means on any future 68K CPU, this EA-mode will get even slower.
 
 
This mode is also very bad on todays Super-Scalar 68K CPUs.
Super-Scalar is a CPU feature which means the CPU can issue/execute more than 1 instruction per cycle.
Examples for such CPUs on 68K are 68060 and 68080.
This EA-mode blocks the Decoder and prevents these CPUs from using Super-Scalar. In other words the instruction block both pipes.
 
To make this clear:
The EA-mode can be "replaced" with 2 normal 68 Instruction.
2 normal 68K instructions use 1 pipe with 2 cycles each.
On a super scalar CPU like 68060 this means 0.5 * 2 = 1 cycle cost - in best case.
 
The EA-MODE needs 4 cycle on blocks 2 pipes = 4 cycle cost.
 
Its very clear to see that on a Super-Scalar CPU this EA-mode is very expensive. As you see the cost of this EA can be 4 times the cost of 2 instructions!
 
 
 
Stefan "Bebbo" Franke wrote:

   
Gunnar von Boehn wrote:
 
      Double indirect blocks Super-Scalar execution, so its in the bigger picture not good for Super-Scalar CPUs like 68060 and 68080.
      Performance wise 68060 and 68080 work better without it.
   

   
    If I read "Super" I expect something better...
 

 
Super-Scalar is a standard known technical term.
It means "a superscalar processor can execute more than one instruction during a clock cycle"
See EXTERNAL LINK   
 
 
Stefan "Bebbo" Franke wrote:
 
   
Gunnar von Boehn wrote:
 
      I think as long GCC makes error on Double-Indirect its a big risk.
   

   
    Using my branch is a risk. So you better go back using the stock version or you do your own branch.
 
 
     
Bebbo, please understand that this is no attack on you.

We all know that GCC is a big and complex program and that improving GCC is not an easy task.
 
Me goal was to report bugs and help you this way to make GCC better.
I don't have the GCC experience to make GCC great.
But maybe I can help you by reporting issues
And I can try to help explain how CPUs execute certain instructions so that some things become clearer.



Samuel Devulder

Posts 248
04 Aug 2019 13:13


Oh! What is going on there? All changes takes time, and there are plenty of them. Let's not pressure Bebbo too much...
 
Anyway, it seem from the GIT that Bebbo has disabled the double indirection code a couple of hours ago. This is a very wise choice for the state being. Once cex & gcc650b get updated, I'll retry to build my exe and check if this hopefully fixes the bug in the exe and possibly the crash as well. This is very interresting.
 
BTW: I found an optim param that might have be good on my exe. this is -freciprocal-math. It basically transform A/B into t=1/B and use A*t. The idea is that 1/B can then be computed earlier in advance so the division-related wait-cycles are hidden. This is considered an unsafe math operation, so it isn't ON by default I presume, but for a game where fps matters, noone cares about unsafe maths ;)


Gildo Addox

Posts 31
05 Aug 2019 06:50


Oh no. THis was such a great thread...

What happened?


Gerardo G.

Posts 54
05 Aug 2019 09:00


From my POV I think there is too much pressure on "Bebbo" to make fast changes on GCC code and on his own code too... I think it is almost the same situation when everyone suggested changes and/or new features on the 68080 too: FPU, 3D Core ... How did you feel then?

So the “Create your own CPU” now is “Fork your own GCC”... Despite I think both answers are not the best ones, I understood Gunnar and Apollo Team then, and now I understand Bebbo too.

It's only my opinion, of course...


Mr Niding

Posts 459
05 Aug 2019 09:05


Gerardo González-Trejo wrote:

From my POV I think there is too much pressure on "Bebbo" to make fast changes on GCC code and on his own code too... I think it is almost the same situation when everyone suggested changes and/or new features on the 68080 too: FPU, 3D Core ... How did you feel then?
 
  So the “Create your own CPU” now is “Fork your own GCC”... Despite I think both answers are not the best ones, I understood Gunnar and Apollo Team then, and now I understand Bebbo too.
 
  It's only my opinion, of course...

Sounds about right.


Gildo Addox

Posts 31
05 Aug 2019 09:36


Sadly, not the first time this has happened in this forum.

It’s not what you say — It’s how you say it!

This thread was really cool to read but at one point there was a pretty harsh comment against Bebbo. I really understand why he left.



Markus B

Posts 209
05 Aug 2019 10:24


Yes, communication problems are often the source of such situations. Maybe the involved parties are already in discussions in the background to resolve the situation. At least I hope so.

Having optimizations in gcc is by far the most promising development for the 68080 since a long time and it would be a huge loss if this enhancement can't be implemented.

My general observation is that the Apollo team needs to rebase themselves in order to extend the software support to a wider audiance. From my perspective, an optimized compiler (gcc or any other) which takes advantage of the excellent hardware designed by Gunnar, is absolulety mandatory to make the Vampire project a bigger success.


Mr Niding

Posts 459
05 Aug 2019 12:08


I havent read every post in this thread, but the posts Ive read didnt seem harsh. Only suggestions from people that obviously understand 680x0 and 68080 code and efficiency very well.

I can see how people can take it as critism, but to me it came off as constructive feedback. Ofcourse the pace of input was quite high, so it adds to workload.

I would say that it would have been better to say "thanks for feedback, but currently its too much work vs spare time" etc.
Totally valid response.

I would say that Apollo Team has given the same feedback time and time again, with for example the FPU demands that was put in their direction, in a barrage manner.

But its easy for me to be an armchair commenter since I dont contribute.


Stefano Briccolani

Posts 586
05 Aug 2019 13:48


Hope that Bebbo and Gunnar could continue this collaboration on Bebbo's Gcc. They are both very talented and passionate about Amiga and can both learn a lot from each other's skills.


Vojin Vidanovic
(Needs Verification)
Posts 1916/ 1
05 Aug 2019 18:37


Hope Bebbo will take his time, and in the end, implement m68k-080 support

If some form of support is needed, would love to hear it from him.


Rollef 2000

Posts 29
06 Aug 2019 07:01


He is gone.
Thanks to the almighties!


Sean Sk

Posts 488
06 Aug 2019 08:02


rollef 2000 wrote:

He is gone.
Thanks to the almighties!

HUH? Why is this a good thing?
I think that's a pretty harsh comment to make. We need people like Bebbo to help with new development on the Amiga.


Mr Niding

Posts 459
06 Aug 2019 08:20


I guess its what I would call "tribalism", where people see the good for one "branch" of a platform as a threat to their "branch".

Instead I would say that the good for either branch is a common good. But hey, having perspective is a negative these days sadly.


Rollef 2000

Posts 29
06 Aug 2019 08:36


sean sk wrote:

  HUH? Why is this a good thing?

That is not good, of course.
I meant that ironically.


Gunnar von Boehn
(Apollo Team Member)
Posts 6207
06 Aug 2019 09:11


I think everyone appreciates Bebbos effort to improve GCC.
GCC is a very huge complex program, so this is certainly not an easy task.
 
The 68K CPU architecture was once extremely popular.
Unfortunately creating good 68K code is still not easy for GCC.

There are many reasons for this:
 
a) 68K supports different EA modes for SRC and DST operands.
    GCC unfortunately only knows EA modes for operants and does not differentiate between SRC and DST.

b) 68K architecture by design have EA-unit and ALU-unit and the implemented CPUs have a vertical pipeline design. Ideally the compiler needs to "model" this to schedule code accordingly. GCC does not model this yet.

c) 68K has market leading code density. 68k offers special instructions and this allows to solve different solution differently to tune code size. GCC needs to model the different options and costs to fully features this.

d) 68K offers an overwhelming amount of different EA-Modes.
To make the best decision of using them the compiler needs to fully understand their costs, their advantages and drawbacks
 
e) the FPU pipeline should be modeled by GCC to allow much higher Flops scores in the future.
 

In short there are many areas where 68k code generation on GCC can be greatly improved. The amount of work for this will be big.
Its great the Bebbo offered to look in this.
 
While we wanted to help with input, maybe it was a bit insensible by us to drown him in a truck load of bug reports and improvement proposals.
 


Markus B

Posts 209
06 Aug 2019 09:55


@Gunnar

Much appreciated your thoughts.
Any chance that you can reach out to Bebbo to clarify the situation? Or possibly this is already ongoing. ;-)


Gildo Addox

Posts 31
06 Aug 2019 10:03


If the amount of work is that big, we could set up a Kickstarter campaign or something similar to pay the work.

What you guys think about that?


Markus B

Posts 209
06 Aug 2019 10:09


That sounds interesting.
I would be willing to donate to such a campaign.


Gunnar von Boehn
(Apollo Team Member)
Posts 6207
06 Aug 2019 11:28


Gildo Addox wrote:

If the amount of work is that big,

I think this is a task and so much work that its really a lot for a single person - ideally this is something for a team.




Gildo Addox

Posts 31
06 Aug 2019 11:37


@Gunnar

Well then, how important is this task? What ist your opinion about how important an optimized GCC for 68k (and the Apollo) is?

Is it a game changer?

posts 367page  1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19