Traditional Synergy Should Provide a .DEFINE (in dbl.def) for D_VALRET
Closed
dbl.def should include a .DEFINE in dbl.def that represents the return value of a ^VAL that correctly accounts for changes in runtime bitness.
This would resolve this issue: https://synergexresourcecenter.force.com/SiteAnswer?id=a2Z0d000000RV97EAG
Steve Ives
8/6/2020 5:26 PM 0
I have discussed your question with development and here's our response.
You're asking for a .DEFINE that defines that maximum size of a ^VAL, but ^VAL does not have a size, it is merely a calling convention that is dependent on the operating system and underlying hardware. It is a high-performance way of passing and returning integer data. Many customers use ^VAL for its performance benefits because a value is passed rather than a descriptor.
It is not possible to define a specific size for a ^VAL at compile time in all scenarios. For example, in Synergy .NET, if code is compiled targeting AnyCpu then the size of a ^VAL is defined at runtime.
You might ask, why not introduce a .define to specify the maximum size of a ^VAL, but again, in the .NET AnyCpu on a 32-bit system scenario, you would not want the performance degradation of using I8 variables for every ^VAL.
If you need to constrain the size of an integer parameter or return value, you should explicitly define the type as an integer, not ^VAL.
If your usage scenario is with addresses then you should use the existing D_ADDR identifier to define the type.
You're asking for a .DEFINE that defines that maximum size of a ^VAL, but ^VAL does not have a size, it is merely a calling convention that is dependent on the operating system and underlying hardware. It is a high-performance way of passing and returning integer data. Many customers use ^VAL for its performance benefits because a value is passed rather than a descriptor.
It is not possible to define a specific size for a ^VAL at compile time in all scenarios. For example, in Synergy .NET, if code is compiled targeting AnyCpu then the size of a ^VAL is defined at runtime.
You might ask, why not introduce a .define to specify the maximum size of a ^VAL, but again, in the .NET AnyCpu on a 32-bit system scenario, you would not want the performance degradation of using I8 variables for every ^VAL.
If you need to constrain the size of an integer parameter or return value, you should explicitly define the type as an integer, not ^VAL.
If your usage scenario is with addresses then you should use the existing D_ADDR identifier to define the type.
8/6/2020 5:26 PM 0
Ace Olszowka
8/6/2020 5:29 PM 0
In the linked Toy Program am I allowed to use D_ADDR as the return value?
8/6/2020 5:29 PM 0
Steve Ives
8/6/2020 5:53 PM 0
If you are caling a system function then you should introduce a .define that is appropriate for whatever type the operation that you are calling returns. In this case the GetProcessHeap function returns a windows HANDLE, which in Synergy an appropriate type would be the same as a D_ADDR, but we'd recommend defining an explicit type to make your code more readable, indicating the variable is a Windows HANDLE. We would do something like this:
.define WINDOWS_HANDLE D_ADDR main record workVars kernel32Handle, D_ADDR processHeap, WINDOWS_HANDLE endrecord proc kernel32Handle = %dll_open( "Kernel32" ) processHeap = GetProcessHeap(kernel32Handle) xcall dll_close(kernel32Handle) endmain function GetProcessHeap ,WINDOWS_HANDLE kernel32Handle, D_ADDR endparams proc freturn %dll_call(kernel32Handle, DLL_TYPE_WINAPI, "GetProcessHeap") end
8/6/2020 5:53 PM 0
Ace Olszowka
8/6/2020 6:11 PM 0
This goes back to the root of this problem that D_ADDR is defined as an I8 in both 64bit and 32bit Synergy which is where the original report and this idea were opened up for, you are wasting 4 bytes on every usage of D_ADDR.
8/6/2020 6:11 PM 0
Steve Ives
8/6/2020 10:07 PM 0
Your statement is incorrect. In traditional Synergy on Windows D_ADDR is an I4 in 32-bit and an I8 in 64-bit. In Synergy .NET D_ADDR is defined as I8 because it is necessary to allow for the fact that the code might be built to target AnyCpu, in which case the size is determined at RUNTIME.
On Windows ^VAL is the same as D_ADDR for size, but not on other platforms. The whole point is that ^VAL is a calling convention where the function declaration determines the ultimately returned size, whose maximum size theoretically (but almost never is unless it's something like a Windows handle) as large as D_ADDR. Except on OpenVMS, where ^VAL is larger than D_ADDR, as D_ADDR on OpenVMS is 32 bits!
We have discussed the matter at length internally and will not be making any changes in this area.
On Windows ^VAL is the same as D_ADDR for size, but not on other platforms. The whole point is that ^VAL is a calling convention where the function declaration determines the ultimately returned size, whose maximum size theoretically (but almost never is unless it's something like a Windows handle) as large as D_ADDR. Except on OpenVMS, where ^VAL is larger than D_ADDR, as D_ADDR on OpenVMS is 32 bits!
We have discussed the matter at length internally and will not be making any changes in this area.
8/6/2020 10:07 PM 0
Ace Olszowka
8/7/2020 1:23 PM 0
Your statement is incorrect. In traditional Synergy on Windows D_ADDR is an I4 in 32-bit and an I8 in 64-bit.
You are correct and I withdraw this statement the commented lines got me:
You are correct and I withdraw this statement the commented lines got me:
8/7/2020 1:23 PM 0
Please log in to comment on this idea.