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.

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

__declspec(fld) to enable 80-bit long double (same as if -fld were given) but on a symbol by symbol basis #1205

Conversation

joncampbell123
Copy link
Contributor

Allow compiled C/C++ code to enable 80-bit long double on a symbol by symbol basis by adding __declspec(fld) to the data type. Allow the __declspec(fld) to function the same as if -fld were enabled at that very point.

This can help enable support for 80-bit long double gradually through the codebase without breaking anything.

Related to #1200

… symbol basis by adding __declspec(fld) to the data type. Allow the __declspec(fld) to function the same as if -fld were enabled at that very point
@joncampbell123
Copy link
Contributor Author

joncampbell123 commented Jan 5, 2024

See also this DOSLIB test program which was updated to test it:

https://github.com/joncampbell123/doslib/blob/master/hw/dos/testprnb.c

First one without -fld, second one with -fld.

db1

@joncampbell123
Copy link
Contributor Author

joncampbell123 commented Jan 5, 2024

If "fld" is not a good __declspec name, or there's a better way to do it, let me know.
The idea is to allow the use of 80-bit long double even if -fld isn't specified by prefixing "long double" with something that overrides the default long double == double mapping. Internal parts of OW could use this to properly handle long double without needing the -fld flag.

The change given here was the best I could do in adding the feature with minimal changes to the code base.

@jmalak
Copy link
Member

jmalak commented Jan 5, 2024

The purpose of the -fld option is to allow a long double to be used as an 80-bit FP including all math functions, etc.
By default long double type is mapped to double type (by FE) all in-line FP math (80bit) is rounded to 64bit FP.
With the -fld option, long double type is not double, but an 80-bit FP type, and all in-line FP math is not rounded to just 64-bit FP and stay with full 80-bit precission.
CRTL gets information from the compiler about what size long double to use and switches all math functions between 64-bit or 80-bit for the long double type and any appropriate math functions.
That something like __declspec(fld) cannot be implemented.

@joncampbell123
Copy link
Contributor Author

The purpose of the -fld option is to allow a long double to be used as an 80-bit FP including all math functions, etc.
By default long double type is mapped to double type (by FE) all in-line FP math (80bit) is rounded to 64bit FP.
With the -fld option, long double type is not double, but an 80-bit FP type, and all in-line FP math is not rounded to just 64-bit FP and stay with full 80-bit precission.
CRTL gets information from the compiler about what size long double to use and switches all math functions between 64-bit or 80-bit for the long double type and any appropriate math functions.
That something like __declspec(fld) cannot be implemented.

The expectation here is only to be able to declare such a variable, even if at this time you can do little else with it due to total lack of support in the CG. I don't know how you expect to fix it without such a feature then.

If use of the declspec triggered a one time warning about lack of math runtime support, would you allow this?

@jmalak
Copy link
Member

jmalak commented Jan 5, 2024

We are discus CRTL solution which doesn't depend on how good is CG long double support.
It must be implemented way as other existing long double 80-bit support by using long_double structure and guarded by _LONG_DOUBLE_ macro.

@jmalak jmalak closed this Feb 14, 2024
@joncampbell123 joncampbell123 deleted the cc-declspec-enable-fld-per-symbol-20240104-1845 branch February 14, 2024 18:52
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants