Which FP package to use for MacOS?

Question

My application uses floats mainly in the MacOS graphics and UI calls, which sometimes  need single or double float parameters.

My existing code (built on VFX 5.2)  has been working well with SSE despite the fixes needed to get the FP-based system calls to work correctly (DFIX, and COCOA-DFIX, etc.).

Are these fixes still needed in VFX 5.4?  The DFIX, etc. code is still present in the Cocoa folder, but it seems to be implied that it are only needed if using the NDP-based FP system.

thank you

Bruno Degazio

Answer 1

v5.4 is designed so that you can use any of the three supported float packs for system calls and/or callbacks. The translation between the selected float pack and the native SSE is performed automagically by the EXTERN: and DEFCALLPROC: parsers and code generators.

These work fine for the System V ABI used by MacOS and Linux, but are much more complex for Windows. This occurs because System V ABI for AMD64 can have six integer and eight float parameters in registers, usually plenty. For Windows, there's a maximum of four register parameters, integer and/or float.

To add to the problems, the Cocoa interface does not use the EXTERN/DEFCALLBACK notation, but instead uses a dual stack notation. ( int1 int2 -- ) ( float1 float2 -- float3 ). Under conditions involving a large number of parameters, the Cocoa notation cannot be correctly code generated. This is especially true under Windows. For this reason alone, the Cocoa dual stack notation is unacceptable, however well it reads. We have to use a notation that can always generate correct code.

Note that we are going to support ARM64 and other CPUs in the future. I do not have the income or the resources to write special case parsers and code generators for each CPU and O/S. Hence all future work will use the EXTERN:/DEFCALLPROC: interface.

Adding new types to the EXTERN:/DEFCALLPROC: interface is straight-forward but sometimes tedious.

Note that the requirement to support more than one FP pack stems from engineering reality. In some application domains 64 bit floats are just inadequate and 80 bit floats are marginally adequate. It would not be difficult to add 128 bit floats to v5.4.

Comments

For what it's worth: the Cocoa package was never intended for Windows. It's Mac only, regardless if 680x0, PPC (hello ARM64), Intel/AMD or ARM64 is used. The inclusion of the Cocoa package in VFX is on request from MPE, not the other way round. Two other vendors distribute it as well. So there're alternatives if needed.

---

My point is not that we are going to withdraw the work we have already done on the dual stack notation. My point is to warn people that there are limits to its use. Outside these limits correct operation is not guaranteed. This will be regardless of the vendor - the problem is inherent in the notation.

Since the Cocoa interface is essentially an Objective C interface, I find it sad that the chosen notation is inadequate. I take your point that the notation was never intended for Windows.

Answer 2

It turned out that the problem was only with a small number of Externs that returned two floats. Unfortunately that included several graphics-related related OS calls needed for drawing and re-sizing windows, which made the problem look much larger than it really was.

PS - I just found out that there is a fix (vfx 5.43) already up on the server. Thanks!