Hi Xavi, Maybe I'm missing something, but it's not exactly clear for me what the patch is meant to solve.
You've introduced a new permanently set macro called HB_OS_WIN64_32, redefined a Harbour type (which should be avoided by all means) and shifted parameter offset by one for reference types, and also deleted ASM guard, but no actual ASM code was deleted. Doing one step back, I don't think you can use the 64-bit method for 32-bit as is, as the calling conventions are much more numerous and complicated in 32-bit. The concept can be used, but it has to cover much more combinations. Maybe the byte array can be a solution. For sure the number of combinations are large, but maybe it can be solved by using a generator program creating the .c source file automatically. Brgds, Viktor On 2010 Feb 10, at 13:06, Xavi wrote: > Hi Viktor, > > To avoid ASM the compiler needs to know the call and sizes at compile time. > Too many combinations for a job that may not be perfect and maybe unused. > It's possible to simplify overwriting the stack with struct of byte array > more call more choice but I think with some optimizations will have problems: > I really don't like either solution. > > Otherwise I think that can be used win64 implement also for win32 with some > modifications. > What do you think of the patch attached (names are irrelevant)? > > Also I would suggest copying items parameters inside HB_WINARG to avoid > changes if they are not passed by reference. > > Best regards, > Xavi > > El 09/02/2010 14:49, Viktor Szakáts escribió: >> Hi, >> >>>> From this point it's users responsibility to >>>> pass parameters properly. >>> >>> Ok. Next topic: coverage of potential C .dll functions. >>> >>> IMO it's unworkable cover functions of n parameters with n size, >>> seems reasonable to restrict to 15 the number of parameters. >> >> This limit already exists, and it should be enough for >> a start. Anyway, once the scheme is developed, it will be >> easy to extend if it's worth it or required. For vast >> majority of cases 15 is enough. >> >>> Currently only covering sizes of 4, 8 bytes in win32 and 8 bytes in win64. >>> This means that calls to PosibleDLLfunc( WORD wPar, BYTE bPar ) are not >>> possible. >> >> 4 and 8 byte parameters are enough for all win32 >> calling conventions. So it's possible to pass BYTE >> already. >> >>> How many types of data have to be supported? >> >> win32: 4 or 8 for arguments, return value can be 4, 8 bytes or double/float. >> plus each in two variations: cdecl or stdcall (winapi) >> win64: 8 for argument, return value is also 8 bytes >> >>> BYTE, WORD, DWORD, PVOID, float, double. >> >> For win64 current solution covers all combinations, as >> there is a much simpler calling convention there, see: >> http://msdn.microsoft.com/en-us/library/ms235286(VS.80).aspx >> >> Brgds, >> Viktor >> > <win_dll.patch>_______________________________________________ > Harbour mailing list (attachment size limit: 40KB) > Harbour@harbour-project.org > http://lists.harbour-project.org/mailman/listinfo/harbour _______________________________________________ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
