1. RE: QWORD (int64) question
- Posted by rudy toews <rltoews at ilos.net> Oct 16, 2002
- 482 views
Elliott Sales de Andrade wrote: > I think I asked this before, but I would like to know how to get return > values that are QWORD's. Someone said that QWORD's are pointers, but > they > are not. When passing QWORD's they use two INT's in VB, so it is > definitely > not 32 bits. I am guessing that I would have to use ASM to do this. From > my > limited knowledge of 16-bit assembler, I happen to know that return > values > that were 32 bits (which was not as usual, of course) were in DX:AX. So, > I'm > guessing that in 32-bit assembly a 64-bit value would be returned in > EDX:EAX. Any help would be appreciated. > > > Euphoria Instant Messenger > Have YOU Joined? > http://groups.yahoo.com/group/euim/ > > hi Elliot while on the actual Euforum i used the search function on the title bar : '64 bit' and got responses which would answer your question. lots of knowledgeable people on the forum. rudy lotterywars
2. RE: QWORD (int64) question
- Posted by Elliott Sales de Andrade <quantum_analyst at hotmail.com> Oct 16, 2002
- 465 views
rudy toews wrote: > >hi Elliot >while on the actual Euforum i used the search function on the title bar >: '64 bit' and got responses which would answer your question. > >lots of knowledgeable people on the forum. > >rudy > > >lotterywars I tried searching on Topica and at the RDS website. I don't believe I found an answer to my question. I did see something about 64-bit floating point values, but they are a different matter. Could you point me to a page that might help? Euphoria Instant Messenger Have YOU Joined? http://groups.yahoo.com/group/euim/
3. RE: QWORD (int64) question
- Posted by Matthew Lewis <matthewwalkerlewis at YAHOO.COM> Oct 17, 2002
- 448 views
> From: Robert Craig [mailto:rds at RapidEuphoria.com] > Elliott Sales de Andrade writes: > > I think I asked this before, but I would like to know how > > to get return values that are QWORD's. Someone said > > that QWORD's are pointers, but they are not. When > > passing QWORD's they use two INT's in VB, so it is definitely > > not 32 bits. I am guessing that I would have to use ASM to do this. > More likely, they use two 32-bit registers. You'd have to > maybe disassemble some compiled C code to get the answer, > and then use some machine code similar to Matt Lewis' DLL code. I found this on http://gcc.gnu.org/ml/gcc-bugs/2000-02/msg00104.html /* * All the functions listed here are C callable, and may also be called * from assembly using the C calling mechanism. All INT64 functions * return their results in edx:eax, where edx is the upper longword. * Functions returning a long place the result in eax, and the contents * of edx are destroyed. All other registers are preserved. */ Based on that, I think this code (untested) should work. The only real change from the standard code (in fptr.e) is that I added the mov edx to get the second dword. A similar fix could be added to the cdecl calls. You can use this to call a function that returns a qword, and it will return a sequence of two 32-bit unsigned integers. When I get a chance, I'll work this into the main lib. include machine.e constant q_fptr_asm = { #60, -- 0: pusha #BB,#00,#00,#00,#00, -- 1: mov ebx, paramcount (2) #B9,#00,#00,#00,#00, -- 6: mov ecx, params (7) -- B: start: #8B,#01, -- B: mov eax, [ecx] #50, -- D: push eax #83,#C1,#04, -- E: add ecx, 4 #4B, -- 11: dec ebx #75,#F7, -- 12: jnz start #FF,#15,#00,#00,#00,#00,-- 14: call dword ptr [comfunc] (22) #A5,#00,#00,#00,#00, -- 1A: mov [retpointer], eax (27) #A3,#00,#00,#00,#00, -- 1A: mov [retpointer], edx (31) #61, -- 20: popa #C3}, -- 21: ret q_fptr_paramcount = 2, q_fptr_params = 7, q_fptr_funcptr = 22+0, q_fptr_retptr = 27+0, q_retval = allocate(8), q_fptr_asm_addr = allocate( length( q_fptr_asm ) + 20 * 5 ) constant q_fptr_func = q_fptr_asm_addr + 33, q_fptr_retval = q_fptr_asm_addr + 37, q_fptr_param_ptr = q_fptr_asm_addr + 41 poke( fptr_asm_q_addr, fptr_q_asm ) poke4( q_fptr_asm_addr + q_fptr_funcptr, fptr_q_func ) poke4( q_fptr_asm_addr + q_fptr_params, q_fptr_param_ptr ) poke4( q_fptr_asm_addr + q_fptr_retptr, q_fptr_retval ) poke4( q_fptr_asm_addr + q_fptr_retptr + 5, q_fptr_retval + 4 ) global function call_fptr_qword( atom fptr, sequence params ) sequence ret -- store the pointer to the function poke4( q_fptr_func, fptr ) -- reverse the params for stdcall calling convention params = reverse(params) -- store the params poke4( q_fptr_param_ptr, params ) -- tell the asm how many params to push poke4( q_fptr_asm_addr + q_fptr_paramcount, length(params) ) -- run the asm call( q_fptr_asm_addr ) -- get the value returned from the function ret = peek4u( {q_fptr_retval,2} ) return ret end function Matt Lewis
4. RE: QWORD (int64) question
- Posted by Elliott Sales de Andrade <quantum_analyst at hotmail.com> Oct 17, 2002
- 450 views
Thanks, it looks great. I'd like to know a few other things first though. First off, to get the first param for that function, I'm using GetProcAddress(). I'm using the value returned from open_dll(). I'm not sure if that is right, so I'd like to know. Second, I have a few functions that need to pass floats. So, how would I do this exactly? Just atom_to_float32() and then bytes_to_int() ? TIA Euphoria Instant Messenger Have YOU Joined? http://groups.yahoo.com/group/euim/ >From: Matthew Lewis <matthewwalkerlewis at YAHOO.COM> > > From: Robert Craig [mailto:rds at RapidEuphoria.com] > > Elliott Sales de Andrade writes: > > > I think I asked this before, but I would like to know how > > > to get return values that are QWORD's. Someone said > > > that QWORD's are pointers, but they are not. When > > > passing QWORD's they use two INT's in VB, so it is definitely > > > not 32 bits. I am guessing that I would have to use ASM to do this. > > > > More likely, they use two 32-bit registers. You'd have to > > maybe disassemble some compiled C code to get the answer, > > and then use some machine code similar to Matt Lewis' DLL code. > >I found this on http://gcc.gnu.org/ml/gcc-bugs/2000-02/msg00104.html > >/* > * All the functions listed here are C callable, and may also be called > * from assembly using the C calling mechanism. All INT64 functions > * return their results in edx:eax, where edx is the upper longword. > * Functions returning a long place the result in eax, and the contents > * of edx are destroyed. All other registers are preserved. > */ > >Based on that, I think this code (untested) should work. The only real >change from the standard code (in fptr.e) is that I added the mov edx to >get >the second dword. A similar fix could be added to the cdecl calls. You >can >use this to call a function that returns a qword, and it will return a >sequence of two 32-bit unsigned integers. When I get a chance, I'll work >this into the main lib. > >include machine.e >constant >q_fptr_asm = { > #60, -- 0: pusha > #BB,#00,#00,#00,#00, -- 1: mov ebx, paramcount (2) > #B9,#00,#00,#00,#00, -- 6: mov ecx, params (7) > -- B: start: > #8B,#01, -- B: mov eax, [ecx] > #50, -- D: push eax > #83,#C1,#04, -- E: add ecx, 4 > #4B, -- 11: dec ebx > #75,#F7, -- 12: jnz start > #FF,#15,#00,#00,#00,#00,-- 14: call dword ptr [comfunc] (22) > #A5,#00,#00,#00,#00, -- 1A: mov [retpointer], eax (27) > #A3,#00,#00,#00,#00, -- 1A: mov [retpointer], edx (31) > #61, -- 20: popa > #C3}, -- 21: ret > >q_fptr_paramcount = 2, >q_fptr_params = 7, >q_fptr_funcptr = 22+0, >q_fptr_retptr = 27+0, >q_retval = allocate(8), > >q_fptr_asm_addr = allocate( length( q_fptr_asm ) + 20 * 5 ) > >constant >q_fptr_func = q_fptr_asm_addr + 33, >q_fptr_retval = q_fptr_asm_addr + 37, >q_fptr_param_ptr = q_fptr_asm_addr + 41 > >poke( fptr_asm_q_addr, fptr_q_asm ) >poke4( q_fptr_asm_addr + q_fptr_funcptr, fptr_q_func ) >poke4( q_fptr_asm_addr + q_fptr_params, q_fptr_param_ptr ) >poke4( q_fptr_asm_addr + q_fptr_retptr, q_fptr_retval ) >poke4( q_fptr_asm_addr + q_fptr_retptr + 5, q_fptr_retval + 4 ) > >global function call_fptr_qword( atom fptr, sequence params ) > sequence ret > -- store the pointer to the function > poke4( q_fptr_func, fptr ) > > -- reverse the params for stdcall calling convention > params = reverse(params) > > -- store the params > poke4( q_fptr_param_ptr, params ) > > -- tell the asm how many params to push > poke4( q_fptr_asm_addr + q_fptr_paramcount, length(params) ) > -- run the asm > call( q_fptr_asm_addr ) > > -- get the value returned from the function > ret = peek4u( {q_fptr_retval,2} ) > return ret >end function > >Matt Lewis
5. RE: QWORD (int64) question
- Posted by Matthew Lewis <matthewwalkerlewis at YAHOO.COM> Oct 18, 2002
- 430 views
> From: Elliott Sales de Andrade [mailto:quantum_analyst at hotmail.com] > Thanks, it looks great. I'd like to know a few other things > first though. > First off, to get the first param for that function, I'm using > GetProcAddress(). I'm using the value returned from > open_dll(). I'm not sure > if that is right, so I'd like to know. Using GetProcAddress() is the correct method, although it's actually pretty easy to get a pointer to a dll function without explicitly calling GetProcAddress(). Just use define_c_variable() instead of define_c_func(). > Second, I have a few > functions that > need to pass floats. So, how would I do this exactly? Just > atom_to_float32() > and then bytes_to_int() ? TIA Yep. Matt Lewis
6. RE: QWORD (int64) question
- Posted by Elliott Sales de Andrade <quantum_analyst at hotmail.com> Oct 20, 2002
- 502 views
Alright, one last set of questions. These QWORD's will, most probably, be signed. So, I'll guess that instead of the line: ret = peek4u({q_fptr_retval, 2}) I'd need to put: ret = {peek4u(q_fptr_retval), peek4s(q_fptr_retval + 4)} to get {unsigned low dword, signed high dword}. And, last question, how would i then put those two values together, if I needed to? I need to test for -1 values. Just multiplying the high dword and adding it to the low dword is good enough? Would that account for the negative? > > > > From: Elliott Sales de Andrade [mailto:quantum_analyst at hotmail.com] > > > Thanks, it looks great. I'd like to know a few other things > > first though. > > First off, to get the first param for that function, I'm using > > GetProcAddress(). I'm using the value returned from > > open_dll(). I'm not sure > > if that is right, so I'd like to know. > >Using GetProcAddress() is the correct method, although it's actually pretty >easy to get a pointer to a dll function without explicitly calling >GetProcAddress(). Just use define_c_variable() instead of define_c_func(). > > > > Second, I have a few > > functions that > > need to pass floats. So, how would I do this exactly? Just > > atom_to_float32() > > and then bytes_to_int() ? TIA > >Yep. > >Matt Lewis
7. RE: QWORD (int64) question
- Posted by Matthew Lewis <matthewwalkerlewis at YAHOO.COM> Oct 28, 2002
- 503 views
> From: Elliott Sales de Andrade [mailto:quantum_analyst at hotmail.com] Sorry for the late reply (been out of town). > Alright, one last set of questions. These QWORD's will, most > probably, be > signed. So, I'll guess that instead of the line: > ret = peek4u({q_fptr_retval, 2}) > I'd need to put: > ret = {peek4u(q_fptr_retval), peek4s(q_fptr_retval + 4)} > to get {unsigned low dword, signed high dword}. > And, last question, how would i then put those two values > together, if I > needed to? I need to test for -1 values. Just multiplying the > high dword and > adding it to the low dword is good enough? Would that account for the > negative? Getting the hi word signed should work fine. Then you could just try: if hi_word < 0 then lo_word = -lo_word end if qword = lo_word + hi_word * #100000000 Of course, make sure that qword is an atom. If the numbers get too big, you will lose some precision (after 15 decimal digits). Matt Lewis