search

bebbo / gcc

Bebbo's gcc-6-branch for m68k-amigaos
GNU General Public License v2.0
33 stars 11 forks source link

Question: 68881 without extended #183

Closed michalsc closed 2 years ago

michalsc commented 2 years ago

Hello!

This is actually neither bug report nor feature request. Rather a question if such feature request would be interesting to you or anyone else. Feel free to wontfix-it if you find the idea rubbish :)

On m68k emulators and JIT translators (such as e.g. my Emu68 project) the cost of loading/storing of floating point numbers in extended format may be awfully expensive for architectures such as AArch64 or PPC, where the built-in fpu supports only single and double formats. Would it eventually make sense to expand gcc with a 68881-double architecture, where costs of all extended loads and stores are set to be extremely huge? Such thing would hopefully force gcc to use fmove.d instead of e.g. fmovem.x for saving/restoring registers.

For comparison: double store/load translated from m68k to aarch64 takes one single ARM instruction, whereas extended load/store translates to 14 instructions.

bebbo commented 2 years ago

Guess it would be possible to add such a switch. But it's not related to costs... it rather affects some instructions:

what else?

michalsc commented 2 years ago

Sorry for late reply. I think this two things should be enough, then if stack frame is set to use doubles, then gcc will do proper fetches and stores already, even for temporal variables stored there (or passed as parameters). Disabling the opcodes would be a no-go I think.

bebbo commented 2 years ago

Please suggest a name for the option, e.g -mschulz ^^ I might have time to work on this soon.

bebbo commented 2 years ago

please test!

michalsc commented 2 years ago

Nice option name :) main branch?

bebbo commented 2 years ago

It's live. And here an example: http://franke.ms/cex/z/rf191T

michalsc commented 2 years ago

I have also checked IT with my portions of code and it all does look good. Good work! Thanks!

Midar commented 2 years ago

I don't think that's a good name for a flag. How about -mavoid-extended-fp or -mextended-fp-is-expensive?

bebbo commented 2 years ago

I don't think that's a good name for a flag. How about -mavoid-extended-fp or -mextended-fp-is-expensive?

I don't think that's a good name either... ... there is time to change the name if it gets merged into the main repo :-)