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

syscall: no way to get at returned float32 value #3588

Closed
gopherbot opened this issue May 3, 2012 · 5 comments
Closed

syscall: no way to get at returned float32 value #3588

gopherbot opened this issue May 3, 2012 · 5 comments

Comments

@gopherbot
Copy link

by smith.malcolm.james:

Calling syscall with float32 arguments passes the values correctly to the dll. But the
float32 return value is incorrect

What steps will reproduce the problem?

visual C++ 6.0 program:
#include "stdafx.h"
#include <stdio.h>
 extern "C"  __declspec(dllexport) float addfloat( float a, float b) ;
BOOL APIENTRY DllMain( HANDLE hModule, 
                       DWORD  ul_reason_for_call, 
                       LPVOID lpReserved
                     )
{
    return TRUE;
}
  float addfloat ( float a, float b)
{
    printf("In dll: %f %f\n", a,b);
    return a+b;
}

Go program:
package main
import (
    "fmt"
    "math"
    "syscall"
)
var mylib = syscall.NewLazyDLL("mylib.dll")
var addfloat = mylib.NewProc("addfloat")
func main() {

    r1, r2, _ := addfloat.Call(uintptr(math.Float32bits(1.1)) , uintptr(math.Float32bits(2.2)))

    fmt.Println("r1 and r2 as uintptr", r1, r2)
    fmt.Println("3.3 as uintptr", uintptr(math.Float32bits(3.3)))

    r1, r2, _ = addfloat.Call(uintptr(math.Float32bits(3.3)) , uintptr(math.Float32bits(4.4)))

    fmt.Println("r1 and r2 as uintptr", r1, r2)
    fmt.Println("7.7 as uintptr", uintptr(math.Float32bits(7.7)))
}


What is the expected output?
Expect r1 to hold IEEE 754 binary representation of 3.3 after 1st call and 7.7 after 2nd
call

What do you see instead?
r1 holds 26 after both 1st and 2nd calls

Sample output:
In dll: 1.100000 2.200000
r1 and r2 as uintptr 26 821312832
3.3 as uintptr 1079194419
In dll: 3.300000 4.400000
r1 and r2 as uintptr 26 821312832
7.7 as uintptr 1089889894

Which compiler are you using (5g, 6g, 8g, gccgo)?
8g

Which operating system are you using?
Windows XP

Which version are you using?  (run 'go version')
go1

Please provide any additional information below.
Integer values are returned with no problem. The code in
src\pkg\runtime\sys_windows_386.s looks as if it is expecting return values to be in the
AX and DX registers, but float values are returned in the ST0 register.
@alexbrainman
Copy link
Member

Comment 1:

This should not be difficult to implement. The issue here is we need to change
syscall.Syscall returned parameters list. This could be big problem.
Can you change your dll interface instead, so it accepts address of where to put return
value, instead of returning it via CPU registers?
Leaving for rsc to decide what to do.
Alex

Labels changed: added os-windows, arch-x86-32.

Owner changed to @alexbrainman.

Status changed to Thinking.

@gopherbot
Copy link
Author

Comment 2 by smith.malcolm.james:

I was just experimenting, its not something I actually need just now. I don't think the
Windows API ever uses floats as return values, so perhaps I will never need it! It would
be nice if it worked, but I appreciate there are issues with changing the parameters to
syscall.

@rsc
Copy link
Contributor

rsc commented Sep 12, 2012

Comment 3:

I think we should leave this as is. I am unaware of any system calls returning floats.
If we do need to add it in the future, we can introduce a syscall.SyscallFloat or some
such.

Status changed to Unfortunate.

@gopherbot
Copy link
Author

Comment 4 by Christoph.Pech:

It's not just important for systemcalls. I need to call sqlite3.dll
sqlite3_column_double() which returns double.

@alexbrainman
Copy link
Member

Comment 5:

Christoph.Pech, we need nice interface to implement required functionality. If you have
good suggestions, please comment.
Alex

Status changed to Duplicate.

Merged into issue #6510.

This issue was closed.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

3 participants