Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

'fpu' option #4

Merged
merged 1 commit into from
Apr 9, 2015
Merged

'fpu' option #4

merged 1 commit into from
Apr 9, 2015

Conversation

TurkeyMan
Copy link
Contributor

Added an 'fpu' option, to select software/hardware FPU (used by arm, mips, etc)

@starkos
Copy link
Member

starkos commented Apr 4, 2015

Could this overlap with the existing floatingpoint() call? Should we just add the values there?

@TurkeyMan
Copy link
Contributor Author

Yeah, I wasn't sure about that.

There are 3 distinct concepts:

  1. hardware availibility ('fpu' as i propose here)
  2. abi ('floatabi')
  3. float codegen options ('floatingpoint', fast/strict/etc)

It doesn't really feel right to conflate any of those. The only one that might not create a mutual exclusion is 'floatingpoint', but i'm not sure about the same mechanism that says to choose fast over strict float support may say there is no FPU hardware? ...maybe it doesn't sound so bad when I say it this way... but it still seems a bit crooked to me.

@starkos
Copy link
Member

starkos commented Apr 6, 2015

My opinion would be to only use two fields if it makes sense to set values from both in parallel, e.g. if something like this would be valid:

fpu "software"
floatingpoint "strict"

Otherwise I would add "software" and "hardware" to floatingpoint(). If the architecture doesn't have FPU hardware then I would expect those values to simply be ignored as we do elsewhere.

floatabi(), on the other hand, does feel like it should be a separate call.

@TurkeyMan
Copy link
Contributor Author

Well there would never be floatingpoint "hardware", because as soon as you have hardware FPU, there will always be various fast/strict/etc tradeoffs.
So floatingpoint "software"/"fast"/"strict"/... seems weird to me, and it seems conceivable that fast/strict tradeoff may be made even in the software context; FPU emulation is slow, and I imagine all sorts of approximations that could be taken to speed it up.

I think I have this correct as presented in this PR.

@TurkeyMan
Copy link
Contributor Author

So how are we feeling about this? I think this PR is right...

starkos added a commit that referenced this pull request Apr 9, 2015
@starkos
Merge pull request #4 from TurkeyMan/manu/fpu
168f91f 
Add new fpu() project API
@starkos starkos merged commit 168f91f into premake:master Apr 9, 2015
@TurkeyMan TurkeyMan deleted the manu/fpu branch April 10, 2015 05:33
martin-traverse pushed a commit to martin-traverse/premake-core that referenced this pull request Apr 19, 2016
@starkos
Merge pull request premake#4 from akaStiX/master
19bfdf2 
Extra warnings
tvandijck pushed a commit to tvandijck/premake-core that referenced this pull request May 11, 2016
@starkos
Merge pull request premake#4 from akaStiX/master
7d80672 
Extra warnings
tvandijck pushed a commit to tvandijck/premake-core that referenced this pull request May 11, 2016
@TurkeyMan
Merge pull request premake#4 from starkos/remove-preload-include
83d3208 
Fix "name in use" errors from module preload script
tvandijck pushed a commit to tvandijck/premake-core that referenced this pull request May 11, 2016
@TurkeyMan
Merge pull request premake#4 from fzwoch/nil_concat_fix
e850f4c 
Fix "concatenate nil value" error
tvandijck pushed a commit to tvandijck/premake-core that referenced this pull request May 11, 2016
@starkos
Merge pull request premake#4 from starkos/rename-solution-to-workspace
77d8740 
Rename solution to workspace everywhere
samsinsane pushed a commit to LORgames/premake-core that referenced this pull request Apr 5, 2018
@pdoane-blizzard
Update RTTI override (premake#4)
f7605c2 
- Add missing condition parameter
- Use cfg.rtti instead of cfg.flags.NoRTTI
vadz added a commit to vadz/premake-core that referenced this pull request Aug 27, 2023
@vadz
Fix crash when enabling debugger under Linux
e739d88 
Rename buffer_init() to avoid clashing with a function with the same
name in luasocket code: under Linux, due to the of "flat" ELF
namespaces, when luasocket shared library is loaded into premake process
the existing premake function is used instead of the function defined in
luasocket code, resulting in luasocket buffer not being properly
initialized which, in turn, leads to mysterious crashes as soon as it's
used, e.g. dereferencing null timeout field:

	(gdb) bt
	#0  0x00007ffff7cce642 in timeout_markstart (tm=0x0) at ../../binmodules/luasocket/src/timeout.c:116
	premake#1  0x00007ffff7cc7618 in buffer_meth_receive (L=0x5555557882a8, buf=0x5555559044a0) at ../../binmodules/luasocket/src/buffer.c:113
	premake#2  0x00007ffff7ccd545 in meth_receive (L=0x5555557882a8) at ../../binmodules/luasocket/src/tcp.c:135
	premake#3  0x000055555558c1cc in luaD_precall (L=0x5555557882a8, func=0x5555558e36b0, nresults=1) at ../../contrib/lua/src/ldo.c:434
	premake#4  0x00005555555a971f in luaV_execute (L=0x5555557882a8) at ../../contrib/lua/src/lvm.c:1134
	premake#5  0x000055555558c555 in luaD_call (L=0x5555557882a8, func=0x5555558e3640, nResults=0) at ../../contrib/lua/src/ldo.c:499
	premake#6  0x000055555558c5b3 in luaD_callnoyield (L=0x5555557882a8, func=0x5555558e3640, nResults=0) at ../../contrib/lua/src/ldo.c:509
	premake#7  0x0000555555588af5 in lua_callk (L=0x5555557882a8, nargs=2, nresults=0, ctx=0, k=0x0) at ../../contrib/lua/src/lapi.c:925
	premake#8  0x00005555555af4f2 in hookf (L=0x5555557882a8, ar=0x7fffffffd270) at ../../contrib/lua/src/ldblib.c:316
	premake#9  0x000055555558bafb in luaD_hook (L=0x5555557882a8, event=2, line=273) at ../../contrib/lua/src/ldo.c:269
	premake#10 0x000055555558b284 in luaG_traceexec (L=0x5555557882a8) at ../../contrib/lua/src/ldebug.c:687
	premake#11 0x00005555555a6b71 in luaV_execute (L=0x5555557882a8) at ../../contrib/lua/src/lvm.c:801
	premake#12 0x000055555558c555 in luaD_call (L=0x5555557882a8, func=0x555555889360, nResults=1) at ../../contrib/lua/src/ldo.c:499
	premake#13 0x000055555558c5b3 in luaD_callnoyield (L=0x5555557882a8, func=0x555555889360, nResults=1) at ../../contrib/lua/src/ldo.c:509
	premake#14 0x0000555555588b60 in f_call (L=0x5555557882a8, ud=0x7fffffffdbb0) at ../../contrib/lua/src/lapi.c:943
	premake#15 0x000055555558b5a5 in luaD_rawrunprotected (L=0x5555557882a8, f=0x555555588b2b <f_call>, ud=0x7fffffffdbb0)
	    at ../../contrib/lua/src/ldo.c:142
	premake#16 0x000055555558cd85 in luaD_pcall (L=0x5555557882a8, func=0x555555588b2b <f_call>, u=0x7fffffffdbb0, old_top=64, ef=48)
	    at ../../contrib/lua/src/ldo.c:729
	premake#17 0x0000555555588c28 in lua_pcallk (L=0x5555557882a8, nargs=0, nresults=1, errfunc=3, ctx=0, k=0x0)
	    at ../../contrib/lua/src/lapi.c:969
	premake#18 0x0000555555584734 in premake_pcall (L=0x5555557882a8, nargs=0, nresults=1) at ../../src/host/premake.c:287
	premake#19 0x0000555555584867 in premake_execute (L=0x5555557882a8, argc=5, argv=0x7fffffffdd98,
	    script=0x555555685052 "src/_premake_main.lua") at ../../src/host/premake.c:316
	premake#20 0x000055555558535e in main (argc=5, argv=0x7fffffffdd98) at ../../src/host/premake_main.c:19

For consistency, rename all the other buffer_xxx functions too, even
though they don't conflict with anything right now.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
2 participants
@TurkeyMan @starkos