Open jirkakunze opened 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.
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.
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?
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.
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.
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)".
fld option is only frontend option. Code generator is still not fixed for 80-bit.
Internal error 136 is for FP constant processing unknown type (long double is still not handled in CG)
How can we support you in implementing the support for 80 bit long doubles?
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.
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.
anyway code generator doesnt have 80-bit type it is processed as structure (custom type)
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.
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?
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.