open-watcom / open-watcom-v2

Open Watcom V2.0 - Source code repository, Wiki, Latest Binary build, Archived builds including all installers for download.
Other
959 stars 157 forks source link

Support for 80bit long doubles #585

Open jirkakunze opened 4 years ago

jirkakunze commented 4 years ago

OpenWatcom implements the type long double as 64bit data type. For the FreeGeos project we need the support of 80bit long doubles. In the sources we have seen that such a support is provided (for example xfloat.h). How can we use this support? Is there a compiler flag for it?

At this point many thanks for maintaining the Watcom Compiler.

jmalak commented 4 years ago

The full support for 80-bit floating point in code generator is not finished. Most of stuff is there. in xfloat.h is declaration of all 80-bit run-time functions used in OW tools. By example these functions are used by math library or by compilers for internal 80-bit FP processing.

jmalak commented 4 years ago

It is necessary finish this support in code generator, without it you can not use 80-bit FP variable in user code. In CRTL all necessary stuff is implemented. In C compiler is experimental option -fld which switch on 80-bit FP support in CRTL (by example FP formatting functions). But still user code can not use 80-bit variables. I think it will not require big effort. But there is general problem for 16-bit Intel architecture for 80-bit FP variables that can not be save into GP registers that code generator must work with 80-bit FP parameter on stack only. I think this stuff is missing, all other is OK. Code generator has defined 80-bit FP type and all compilers too, but it is switch off by definition that long double is double type in compilers.

rdos314 commented 4 years ago

But isn't it rather "standard" to pass FP variables either as pointers or in FP registers? I don't see the advantage of passing them in ordinary CPU registers. Besides, aren't there #pragma aux that lets you define 80-bit FP registers as passed in FPU registers?

If there is a problem with the 16-bit environment, perhaps the long double type could be defined as 80-bit for 32-bit code and double for 16-bit code?

jmalak commented 4 years ago

It is mainly for code if no FPU is used. May be I don't remember correctly about all things. Anyway it is solvable by passing 80-bit FP numbers by pointers to memory location and not use GP registers. Any of 80-bit FP must be always in memory that it could not be big problem to define 80-bit number stuff to use always temporary/memory and not allocate GP register for it.

jmalak commented 4 years ago

Anyway it should be the same technique as for MMX/XMM/SSE FP registers and variables. But there is no problem with no FPU stuff only with features.

jirkakunze commented 4 years ago

I experimented with the current Watcom and Flag -fld.Whenever I use the datatype long double there is an "Error! E1119: Internal compiler error 136 Segmentation fault (core dumped)".

jmalak commented 4 years ago

fld option is only frontend option. Code generator is still not fixed for 80-bit.

jmalak commented 4 years ago

Internal error 136 is for FP constant processing unknown type (long double is still not handled in CG)

jirkakunze commented 4 years ago

How can we support you in implementing the support for 80 bit long doubles?

jirkakunze commented 4 years ago

I have looked at the generated code when double is used. It should be enought to replace the FLD mem64 and FSTP mem64 instructions with their mem80 versions. The mem80 versions are supported since 80x87.

jmalak commented 4 years ago

Not as simple as it looks. The necessary changes are all 80-bit support functions. For FPU inline mode mainly 80-bit allocation and copy support is necessary, generator for inline FPU instructions is there. For other FPU mode more changes are necessary. By example FP call mode requires implement more CRTL support functions etc. I prepared some macros for 80-bit FP support which start with mapping to 64-bit FP code as now that it will be possible to implement appropriate functions (we will know what is exactly necessary). I have these changes in my local git repository to test them that don't break existing functionality. As soon as I will finish tests I will submit it to OW repository to be visible what is missing and will need to implement for full 80-bit FP support.

jmalak commented 4 years ago

anyway code generator doesnt have 80-bit type it is processed as structure (custom type)

jmalak commented 4 years ago

I submit first commit which prepare development environment for 80-bit long double support It is activated by macro FP80BIT_DEVELOPMENT in _cgstd.h header file Initially I did necessary change to remove any mapping of long double type to double type add all necessary run-time conversion function definition (only definition, implementation must be developed and add to CRTL). Anybody can now start with contribution.

jirkakunze commented 3 years ago

I have looked at your preparations. The necessary changes are more extensive than I had expected. I have not yet understood all the parts that need to be adjusted. Can you help us to complete the 80bit long double support?