Re: AMD64 ABI compatibility
Hi Nickolas, Nicolas Alt wrote on 02.08.2007 03:51:35: Kai, did you make your diff against the current CVS checkout or against your first patch? Should your changes already work for some cases? I would like to test if they produce the right instructions. However, I do not have enough insight into gcc to work on it myself. Thanks, Nicolas Yes, it is a diff against svn head and contain the complete patch so far. This patch is currently not complete and needs some cleanups too. But may you can use it to try some first steps. Cheers, i.A. Kai Tietz | (\_/) This is Bunny. Copy and paste Bunny | (='.'=) into your signature to help him gain | ()_() world domination. -- OneVision Software Entwicklungs GmbH Co. KG Dr.-Leo-Ritter-Straße 9 - 93049 Regensburg Tel: +49.(0)941.78004.0 - Fax: +49.(0)941.78004.489 - www.OneVision.com Commerzbank Regensburg - BLZ 750 400 62 - Konto 6011050 Handelsregister: HRA 6744, Amtsgericht Regensburg Komplementärin: OneVision Software Entwicklungs Verwaltungs GmbH Dr.-Leo-Ritter-Straße 9 – 93049 Regensburg Handelsregister: HRB 8932, Amtsgericht Regensburg - Geschäftsführer: Ulrike Döhler, Manuela Kluger
Re: AMD64 ABI compatibility
Hi Jan,
Jan Hubicka wrote on 31.07.2007 23:40:40:
Hi Kai,
so, could you resolve the remaining issues? Or have you kind of
paused the project?
Cheers,
Nicolas
On Jul 12, 2007, at 2:14 , Kai Tietz wrote:
Hi,
I am nearly through :) The remaining macros left to be ported are
REGPARM_MAX and SSE_REGPARM_MAX. The sysv_abi uses 6 regs and 8 sses,
ms_abi uses 4 regs and 4 sse registers. The problem is for example
the use
in i386.md of SSE_REGPARM_MAX without any hint, how to choose the
required
abi. Do you have an idea how this could be done ?
This shoul not be dificult - ix86_regparm is used in
ix86_function_regparm, init_cumulative_args, setup_incoming_varargs_64
functions. In all those cases you know the function declaration and
thus you can take a look if it is call to different ABI and overwrite
the value.
Ok, here is my update.
Cheers,
i.A. Kai Tietz
| (\_/) This is Bunny. Copy and paste Bunny
| (='.'=) into your signature to help him gain
| ()_() world domination.
--
OneVision Software Entwicklungs GmbH Co. KG
Dr.-Leo-Ritter-Straße 9 - 93049 Regensburg
Tel: +49.(0)941.78004.0 - Fax: +49.(0)941.78004.489 - www.OneVision.com
Commerzbank Regensburg - BLZ 750 400 62 - Konto 6011050
Handelsregister: HRA 6744, Amtsgericht Regensburg
Komplementärin: OneVision Software Entwicklungs Verwaltungs GmbH
Dr.-Leo-Ritter-Straße 9 – 93049 Regensburg
Handelsregister: HRB 8932, Amtsgericht Regensburg - Geschäftsführer:
Ulrike Döhler, Manuela Kluger
Index: gcc/gcc/calls.c
===
--- gcc.orig/gcc/calls.c
+++ gcc/gcc/calls.c
@@ -1187,6 +1187,7 @@ initialize_argument_information (int num
static int
compute_argument_block_size (int reg_parm_stack_space,
struct args_size *args_size,
+tree fndecl, //
int preferred_stack_boundary ATTRIBUTE_UNUSED)
{
int unadjusted_args_size = args_size-constant;
@@ -1224,7 +1225,7 @@ compute_argument_block_size (int reg_par
/* The area corresponding to register parameters is not to count in
the size of the block we need. So make the adjustment. */
- if (!OUTGOING_REG_PARM_STACK_SPACE)
+ if (!OUTGOING_REG_PARM_STACK_SPACE (fndecl))
args_size-var
= size_binop (MINUS_EXPR, args_size-var,
ssize_int (reg_parm_stack_space));
@@ -1245,7 +1246,7 @@ compute_argument_block_size (int reg_par
args_size-constant = MAX (args_size-constant,
reg_parm_stack_space);
- if (!OUTGOING_REG_PARM_STACK_SPACE)
+ if (!OUTGOING_REG_PARM_STACK_SPACE (fndecl))
args_size-constant -= reg_parm_stack_space;
}
return unadjusted_args_size;
@@ -2036,7 +2037,7 @@ expand_call (tree exp, rtx target, int i
reg_parm_stack_space = REG_PARM_STACK_SPACE (fndecl);
#endif
- if (!OUTGOING_REG_PARM_STACK_SPACE reg_parm_stack_space 0 PUSH_ARGS)
+ if (!OUTGOING_REG_PARM_STACK_SPACE (fndecl) reg_parm_stack_space 0
PUSH_ARGS)
must_preallocate = 1;
/* Set up a place to return a structure. */
@@ -2442,7 +2443,7 @@ expand_call (tree exp, rtx target, int i
/* Since we will be writing into the entire argument area,
the map must be allocated for its entire size, not just
the part that is the responsibility of the caller. */
- if (!OUTGOING_REG_PARM_STACK_SPACE)
+ if (!OUTGOING_REG_PARM_STACK_SPACE (fndecl))
needed += reg_parm_stack_space;
#ifdef ARGS_GROW_DOWNWARD
@@ -2541,7 +2542,7 @@ expand_call (tree exp, rtx target, int i
{
rtx push_size
= GEN_INT (adjusted_args_size.constant
- + (OUTGOING_REG_PARM_STACK_SPACE ? 0
+ + (OUTGOING_REG_PARM_STACK_SPACE (fndecl) ? 0
: reg_parm_stack_space));
if (old_stack_level == 0)
{
@@ -2712,7 +2713,7 @@ expand_call (tree exp, rtx target, int i
/* If register arguments require space on the stack and stack space
was not preallocated, allocate stack space here for arguments
passed in registers. */
- if (OUTGOING_REG_PARM_STACK_SPACE !ACCUMULATE_OUTGOING_ARGS
+ if (OUTGOING_REG_PARM_STACK_SPACE (fndecl) !ACCUMULATE_OUTGOING_ARGS
must_preallocate == 0 reg_parm_stack_space 0)
anti_adjust_stack (GEN_INT (reg_parm_stack_space));
@@ -3537,7 +3538,7 @@ emit_library_call_value_1 (int retval, r
args_size.constant = MAX (args_size.constant,
reg_parm_stack_space);
- if (!OUTGOING_REG_PARM_STACK_SPACE)
+ if (!OUTGOING_REG_PARM_STACK_SPACE (fndecl))
Re: AMD64 ABI compatibility
Kai, did you make your diff against the current CVS checkout or against your first patch? Should your changes already work for some cases? I would like to test if they produce the right instructions. However, I do not have enough insight into gcc to work on it myself. Thanks, Nicolas On Aug 1, 2007, at 5:48 , Kai Tietz wrote: Hi Jan, Jan Hubicka wrote on 31.07.2007 23:40:40: Hi Kai, so, could you resolve the remaining issues? Or have you kind of paused the project? Cheers, Nicolas On Jul 12, 2007, at 2:14 , Kai Tietz wrote: Hi, I am nearly through :) The remaining macros left to be ported are REGPARM_MAX and SSE_REGPARM_MAX. The sysv_abi uses 6 regs and 8 sses, ms_abi uses 4 regs and 4 sse registers. The problem is for example the use in i386.md of SSE_REGPARM_MAX without any hint, how to choose the required abi. Do you have an idea how this could be done ? This shoul not be dificult - ix86_regparm is used in ix86_function_regparm, init_cumulative_args, setup_incoming_varargs_64 functions. In all those cases you know the function declaration and thus you can take a look if it is call to different ABI and overwrite the value. Ok, here is my update. Cheers, i.A. Kai Tietz | (\_/) This is Bunny. Copy and paste Bunny | (='.'=) into your signature to help him gain | ()_() world domination. -- OneVision Software Entwicklungs GmbH Co. KG Dr.-Leo-Ritter-Straße 9 - 93049 Regensburg Tel: +49.(0)941.78004.0 - Fax: +49.(0)941.78004.489 - www.OneVision.com Commerzbank Regensburg - BLZ 750 400 62 - Konto 6011050 Handelsregister: HRA 6744, Amtsgericht Regensburg Komplementärin: OneVision Software Entwicklungs Verwaltungs GmbH Dr.-Leo-Ritter-Straße 9 – 93049 Regensburg Handelsregister: HRB 8932, Amtsgericht Regensburg - Geschäftsführer: Ulrike Döhler, Manuela Kluger amd64_abis_2.txt
Re: AMD64 ABI compatibility
Hi Nicolas, Nicolas Alt wrote on 30.07.2007 23:29:32: so, could you resolve the remaining issues? Or have you kind of paused the project? I prepared allready a first patch and sent it to Jan. The major problem is the strong wired target specific definitons for the SSE_REG_MAX, ect. used in i386.md without the chance to get the knowledge of the origin calling abi. This is reason why this project stopped. I am waiting for some comments back of Jan to continue. Cheers, i.A. Kai Tietz | (\_/) This is Bunny. Copy and paste Bunny | (='.'=) into your signature to help him gain | ()_() world domination. -- OneVision Software Entwicklungs GmbH Co. KG Dr.-Leo-Ritter-Straße 9 - 93049 Regensburg Tel: +49.(0)941.78004.0 - Fax: +49.(0)941.78004.489 - www.OneVision.com Commerzbank Regensburg - BLZ 750 400 62 - Konto 6011050 Handelsregister: HRA 6744, Amtsgericht Regensburg Komplementärin: OneVision Software Entwicklungs Verwaltungs GmbH Dr.-Leo-Ritter-Straße 9 – 93049 Regensburg Handelsregister: HRB 8932, Amtsgericht Regensburg - Geschäftsführer: Ulrike Döhler, Manuela Kluger
Re: AMD64 ABI compatibility
Hi Kai, so, could you resolve the remaining issues? Or have you kind of paused the project? Cheers, Nicolas On Jul 12, 2007, at 2:14 , Kai Tietz wrote: Hi, I am nearly through :) The remaining macros left to be ported are REGPARM_MAX and SSE_REGPARM_MAX. The sysv_abi uses 6 regs and 8 sses, ms_abi uses 4 regs and 4 sse registers. The problem is for example the use in i386.md of SSE_REGPARM_MAX without any hint, how to choose the required abi. Do you have an idea how this could be done ? This shoul not be dificult - ix86_regparm is used in ix86_function_regparm, init_cumulative_args, setup_incoming_varargs_64 functions. In all those cases you know the function declaration and thus you can take a look if it is call to different ABI and overwrite the value. Honza Cheers, i.A. Kai Tietz | (\_/) This is Bunny. Copy and paste Bunny | (='.'=) into your signature to help him gain | ()_() world domination. -- OneVision Software Entwicklungs GmbH Co. KG Dr.-Leo-Ritter-Straße 9 - 93049 Regensburg Tel: +49.(0)941.78004.0 - Fax: +49.(0)941.78004.489 - www.OneVision.com Commerzbank Regensburg - BLZ 750 400 62 - Konto 6011050 Handelsregister: HRA 6744, Amtsgericht Regensburg Komplementärin: OneVision Software Entwicklungs Verwaltungs GmbH Dr.-Leo-Ritter-Straße 9 ? 93049 Regensburg Handelsregister: HRB 8932, Amtsgericht Regensburg - Geschäftsführer: Ulrike Döhler, Manuela Kluger
Re: AMD64 ABI compatibility
Hi Kai, so, could you resolve the remaining issues? Or have you kind of paused the project? Cheers, Nicolas On Jul 12, 2007, at 2:14 , Kai Tietz wrote: Hi, I am nearly through :) The remaining macros left to be ported are REGPARM_MAX and SSE_REGPARM_MAX. The sysv_abi uses 6 regs and 8 sses, ms_abi uses 4 regs and 4 sse registers. The problem is for example the use in i386.md of SSE_REGPARM_MAX without any hint, how to choose the required abi. Do you have an idea how this could be done ? Cheers, i.A. Kai Tietz | (\_/) This is Bunny. Copy and paste Bunny | (='.'=) into your signature to help him gain | ()_() world domination. -- OneVision Software Entwicklungs GmbH Co. KG Dr.-Leo-Ritter-Straße 9 - 93049 Regensburg Tel: +49.(0)941.78004.0 - Fax: +49.(0)941.78004.489 - www.OneVision.com Commerzbank Regensburg - BLZ 750 400 62 - Konto 6011050 Handelsregister: HRA 6744, Amtsgericht Regensburg Komplementärin: OneVision Software Entwicklungs Verwaltungs GmbH Dr.-Leo-Ritter-Straße 9 – 93049 Regensburg Handelsregister: HRB 8932, Amtsgericht Regensburg - Geschäftsführer: Ulrike Döhler, Manuela Kluger
Re: AMD64 ABI compatibility
Hi, I am nearly through :) The remaining macros left to be ported are REGPARM_MAX and SSE_REGPARM_MAX. The sysv_abi uses 6 regs and 8 sses, ms_abi uses 4 regs and 4 sse registers. The problem is for example the use in i386.md of SSE_REGPARM_MAX without any hint, how to choose the required abi. Do you have an idea how this could be done ? Cheers, i.A. Kai Tietz | (\_/) This is Bunny. Copy and paste Bunny | (='.'=) into your signature to help him gain | ()_() world domination. -- OneVision Software Entwicklungs GmbH Co. KG Dr.-Leo-Ritter-Straße 9 - 93049 Regensburg Tel: +49.(0)941.78004.0 - Fax: +49.(0)941.78004.489 - www.OneVision.com Commerzbank Regensburg - BLZ 750 400 62 - Konto 6011050 Handelsregister: HRA 6744, Amtsgericht Regensburg Komplementärin: OneVision Software Entwicklungs Verwaltungs GmbH Dr.-Leo-Ritter-Straße 9 – 93049 Regensburg Handelsregister: HRB 8932, Amtsgericht Regensburg - Geschäftsführer: Ulrike Döhler, Manuela Kluger
Re: AMD64 ABI compatibility
Jan Hubicka wrote on 11.07.2007 02:02:13: I am on that tricky thing ;) I think I need in i386.c an global variable ix86_amd64_abi which helds the the current function abi. This means also that I have to use instead of TARGET_64BIT_MS_ABI this variable.This var may initioalized by init_cumulative_args and the overriden REG_PARM_STACK_SPACE, OUTGOING_REG_PARM_STACK_SPACE, REGPARM_MAX, SSE_REGPARM_MAX, STACK_BOUNDARY, etc. In order to get all cases right (ie switching ABIs and calling foreign function), you need more bookkeeping than this. I am just in hurry to catch bus, but I will send you little guide tonight. Hi, so short overview. It seems to me that you have several cases: - to keep track of current function ABI, you need to add struct machine_function field (i386.g) and update TARGET_64BIT_MS_ABI that cares about current function ABI accordingly. To deal correclty with call_used registers, I think you need to set the bits at same time machine_function is initialized and add a function to regalloc that will update the internal representaiton via regset (grep for use of the macro). For example prologue/epologue code cares about this current ABI. - to keep track of ABI used by currently expanded function call CUMULATIVE_ARGS allows you to add extra info. See how cum-nregs is handled, you need to do pretty much the same and add cum argument to functions called form cumulative arguments machinery where youneed them. (as opposed to flipping the current abi above as you suggested). There is one problem that RTL CALL instructions does not specify call used registers that differ in between ABI. They are all assumed to use ones specified by call_used. I think you can't do anything to declare SI/DI unused when calling function from SYSV ABI with MS ABI convention. We just lose code quality a bit. On the other hand you must specify them as clobbered when calling SYSV ABI from MS ABI. This needs to be done by adding extra variants of call instruction pattern with the clobber. You might want to impleement SYSV-MS direction only first and not worry about this for start. Note that when calling libcalls, you always want to use the efault conventions so the libgcc match. - You need to keep track of cases function from one ABI calls functions from different ABI. This can be done by adding yet another bit into machine_function and simply set it when expanding the foreign call. Some predicates (such as ix86_function_value_regno_p) cares about if the reg can possibly be return value. In the case both ABIs coexist in single function, you need to be conservative here and merge both possibilities. - You will need to update the calling convention of some of the predicates you mentioned (such as I think OUTGOING_REG_PARM_STACK_SPACE) to specify the function declaration they care about (so you know if it is foreign call or not). GCC middleend is probably not quite ready to deal with so different ABIs intermixed at once. This include updating of calling conventions in all ports and should be done first by separate patches. Not dificult, but tedious. I guess thats it. I believe that if you don't do something of the above, some of cases will go wildly wrong... (this is not to discougrate you, just to explain why it is tricky :) Honza I thank you very much for your great help. Currently I am stucked on x86_function_value_regno_p (macro FUNCTION_VALUE_REGNO_P). It is not clear what's to do here for the FIRST_FLOAT_REG case. Maybe I could use the ms_abi variant for sysv_abi as default too. But I think, it breaks 87 fpu stuff for this ABI !?! Cheers, i.A. Kai Tietz | (\_/) This is Bunny. Copy and paste Bunny | (='.'=) into your signature to help him gain | ()_() world domination. -- OneVision Software Entwicklungs GmbH Co. KG Dr.-Leo-Ritter-Straße 9 - 93049 Regensburg Tel: +49.(0)941.78004.0 - Fax: +49.(0)941.78004.489 - www.OneVision.com Commerzbank Regensburg - BLZ 750 400 62 - Konto 6011050 Handelsregister: HRA 6744, Amtsgericht Regensburg Komplementärin: OneVision Software Entwicklungs Verwaltungs GmbH Dr.-Leo-Ritter-Straße 9 – 93049 Regensburg Handelsregister: HRB 8932, Amtsgericht Regensburg - Geschäftsführer: Ulrike Döhler, Manuela Kluger
Re: AMD64 ABI compatibility
I thank you very much for your great help. Currently I am stucked on x86_function_value_regno_p (macro FUNCTION_VALUE_REGNO_P). It is not clear what's to do here for the FIRST_FLOAT_REG case. Maybe I could use the ms_abi variant for sysv_abi as default too. But I think, it breaks 87 fpu stuff for this ABI !?! x86_function_value_regno_p is tricky one. Speaking strictly from definition I think it should - for current SYSV ABI with no MS ABI function calls return set it returns for MS ABI (not including x87) - for current SYSV ABI or MS ABI with SYSV ABI function calls return set it returns for SYSV ABI (including x87) However see the use in builtins.c - it expects that this function is invariant for whole compilation unit, so implementing the above would need updating builtins.c too. The feature is used just seldomly - for the extra builtin expansion, in combine.c for logic that won't fire for x87, in mode switching to support the builtin_apply above and in rtlanal.c to avoid separating the return value from call. With x87 register we should not be spoiled here either, since x87 is quite symetric before regstack and restack will know how to fix this up. My best bet would be that making the function dependent on default ABI is good enough. You might add some comment that the function should depend on current function ABI but builtins.c would need updating then. Honza Cheers, i.A. Kai Tietz | (\_/) This is Bunny. Copy and paste Bunny | (='.'=) into your signature to help him gain | ()_() world domination. -- OneVision Software Entwicklungs GmbH Co. KG Dr.-Leo-Ritter-Straße 9 - 93049 Regensburg Tel: +49.(0)941.78004.0 - Fax: +49.(0)941.78004.489 - www.OneVision.com Commerzbank Regensburg - BLZ 750 400 62 - Konto 6011050 Handelsregister: HRA 6744, Amtsgericht Regensburg Komplementärin: OneVision Software Entwicklungs Verwaltungs GmbH Dr.-Leo-Ritter-Straße 9 ??? 93049 Regensburg Handelsregister: HRB 8932, Amtsgericht Regensburg - Geschäftsführer: Ulrike Döhler, Manuela Kluger
Re: AMD64 ABI compatibility
Jan Hubicka wrote on 11.07.2007 14:01:54: I thank you very much for your great help. Currently I am stucked on x86_function_value_regno_p (macro FUNCTION_VALUE_REGNO_P). It is not clear what's to do here for the FIRST_FLOAT_REG case. Maybe I could use the ms_abi variant for sysv_abi as default too. But I think, it breaks 87 fpu stuff for this ABI !?! x86_function_value_regno_p is tricky one. Speaking strictly from definition I think it should - for current SYSV ABI with no MS ABI function calls return set it returns for MS ABI (not including x87) - for current SYSV ABI or MS ABI with SYSV ABI function calls return set it returns for SYSV ABI (including x87) However see the use in builtins.c - it expects that this function is invariant for whole compilation unit, so implementing the above would need updating builtins.c too. The feature is used just seldomly - for the extra builtin expansion, in combine.c for logic that won't fire for x87, in mode switching to support the builtin_apply above and in rtlanal.c to avoid separating the return value from call. With x87 register we should not be spoiled here either, since x87 is quite symetric before regstack and restackwill know how to fix this up. My best bet would be that making the function dependent on default ABI is good enough. You might add some comment that the function should depend on current function ABI but builtins.c would need updating then. Honza I noticed, that OUTGOING_REG_PARM_STACK_SPACE makes troubles too. What is about extending this macro by a FNDECL argument ? This would solve the problem and AFAICS the function declaration seems to be always present. Cheers, i.A. Kai Tietz | (\_/) This is Bunny. Copy and paste Bunny | (='.'=) into your signature to help him gain | ()_() world domination. -- OneVision Software Entwicklungs GmbH Co. KG Dr.-Leo-Ritter-Straße 9 - 93049 Regensburg Tel: +49.(0)941.78004.0 - Fax: +49.(0)941.78004.489 - www.OneVision.com Commerzbank Regensburg - BLZ 750 400 62 - Konto 6011050 Handelsregister: HRA 6744, Amtsgericht Regensburg Komplementärin: OneVision Software Entwicklungs Verwaltungs GmbH Dr.-Leo-Ritter-Straße 9 – 93049 Regensburg Handelsregister: HRB 8932, Amtsgericht Regensburg - Geschäftsführer: Ulrike Döhler, Manuela Kluger
Re: AMD64 ABI compatibility
Jan Hubicka wrote on 11.07.2007 14:01:54: I thank you very much for your great help. Currently I am stucked on x86_function_value_regno_p (macro FUNCTION_VALUE_REGNO_P). It is not clear what's to do here for the FIRST_FLOAT_REG case. Maybe I could use the ms_abi variant for sysv_abi as default too. But I think, it breaks 87 fpu stuff for this ABI !?! x86_function_value_regno_p is tricky one. Speaking strictly from definition I think it should - for current SYSV ABI with no MS ABI function calls return set it returns for MS ABI (not including x87) - for current SYSV ABI or MS ABI with SYSV ABI function calls return set it returns for SYSV ABI (including x87) However see the use in builtins.c - it expects that this function is invariant for whole compilation unit, so implementing the above would need updating builtins.c too. The feature is used just seldomly - for the extra builtin expansion, in combine.c for logic that won't fire for x87, in mode switching to support the builtin_apply above and in rtlanal.c to avoid separating the return value from call. With x87 register we should not be spoiled here either, since x87 is quite symetric before regstack and restackwill know how to fix this up. My best bet would be that making the function dependent on default ABI is good enough. You might add some comment that the function should depend on current function ABI but builtins.c would need updating then. Honza I noticed, that OUTGOING_REG_PARM_STACK_SPACE makes troubles too. What is about extending this macro by a FNDECL argument ? This would solve the problem and AFAICS the function declaration seems to be always present. Yes, this is what I would suggest. There is little trickery here - OUTGOING_REG_PARM_STACK_SPACE is used in calls.c where it is function call specific and I think adding decl argument will just do the right thing. Other use is in definition of STACK_DYNAMIC_OFFSET use in function.c This case however cares if REG_PARM_STACK_SPACE is present in currently compiled function (that is if the current function has some call in MS ABI mode). I guess this can be dealt with adding CURRENT_FUNCTOIN_OUTGOING_REG_PARM_STACK_SPACE that would DRT, but we need to double check that defining it won't move all function arguments away from top of stack breaking any calls to SYSV ABI mode in the same function. I am about to leave again, I will try to look into the implementation later today (I am just about to leave now) Honza Cheers, i.A. Kai Tietz | (\_/) This is Bunny. Copy and paste Bunny | (='.'=) into your signature to help him gain | ()_() world domination. -- OneVision Software Entwicklungs GmbH Co. KG Dr.-Leo-Ritter-Straße 9 - 93049 Regensburg Tel: +49.(0)941.78004.0 - Fax: +49.(0)941.78004.489 - www.OneVision.com Commerzbank Regensburg - BLZ 750 400 62 - Konto 6011050 Handelsregister: HRA 6744, Amtsgericht Regensburg Komplementärin: OneVision Software Entwicklungs Verwaltungs GmbH Dr.-Leo-Ritter-Straße 9 ??? 93049 Regensburg Handelsregister: HRB 8932, Amtsgericht Regensburg - Geschäftsführer: Ulrike Döhler, Manuela Kluger
Re: AMD64 ABI compatibility
On 09 July 2007 20:48, Nicolas Alt wrote: Hi! On the AMD64 / x86-64Bit architecture, some arguments of a functions are passed using registers, but there seem to be two different conventions out there. The standard ABI uses 6 registers, but Microsoft compilers use only 4. Because of that, code compiled with gcc cannot call code compiled with a MS compiler without an ugly wrapper. Have there been any efforts to make gcc do function calls the MS way? I guess this would be an important feature for mingw on AMD64. Does -mregparm=4 do what you want? Windows and GCC ABIs are on x86-64 more different than that (they was historically developed in parallel). GCC 4.3 will support attribute for this calling convention contributed by Kai Tiez and Richard Henderson, but before that there is not much to do... Honza cheers, DaveK -- Can't think of a witty .sigline today
Re: AMD64 ABI compatibility
On 09 July 2007 20:48, Nicolas Alt wrote: Hi! On the AMD64 / x86-64Bit architecture, some arguments of a functions are passed using registers, but there seem to be two different conventions out there. The standard ABI uses 6 registers, but Microsoft compilers use only 4. Because of that, code compiled with gcc cannot call code compiled with a MS compiler without an ugly wrapper. Have there been any efforts to make gcc do function calls the MS way? I guess this would be an important feature for mingw on AMD64. Does -mregparm=4 do what you want? Windows and GCC ABIs are on x86-64 more different than that (they was historically developed in parallel). GCC 4.3 will support attribute for this calling convention contributed by Kai Tiez and Richard Henderson, but before that there is not much to do... Note: My name is Kai Tietz ;) not Tiez I think, it isn't to hard introducing this attributes to the AMD64 abi's. What names should we use for it? I suggest x86_64_ms and x86_64_linux. Is this ok for you. Cheers, i.A. Kai Tietz | (\_/) This is Bunny. Copy and paste Bunny | (='.'=) into your signature to help him gain | ()_() world domination. -- OneVision Software Entwicklungs GmbH Co. KG Dr.-Leo-Ritter-Straße 9 - 93049 Regensburg Tel: +49.(0)941.78004.0 - Fax: +49.(0)941.78004.489 - www.OneVision.com Commerzbank Regensburg - BLZ 750 400 62 - Konto 6011050 Handelsregister: HRA 6744, Amtsgericht Regensburg Komplementärin: OneVision Software Entwicklungs Verwaltungs GmbH Dr.-Leo-Ritter-Straße 9 – 93049 Regensburg Handelsregister: HRB 8932, Amtsgericht Regensburg - Geschäftsführer: Ulrike Döhler, Manuela Kluger
Re: AMD64 ABI compatibility
Windows and GCC ABIs are on x86-64 more different than that (they was historically developed in parallel). GCC 4.3 will support attribute for this calling convention contributed by Kai Tiez and Richard Henderson, but before that there is not much to do... Note: My name is Kai Tietz ;) not Tiez I think, it isn't to hard introducing this attributes to the AMD64 abi's. What names should we use for it? I suggest x86_64_ms and x86_64_linux. For code bridging MS and GNU codebases (such as wine, or lets say, GNU runtime in windows if it ends up with non-MS calling convetions). Then you want to use the attributes to call code from foreign world. x86_64_linux is probably not very exact - we intended the ABI to be generally useful for non-linux or non-GNU system (i.e. specified as System V Application Binary Interface AMD64 Architecture Processor Supplement with GCC as reference implementation). I believe Sparc and other unixes are more or less following it too. For MS I would probably suggest ms_abi (it makes it cleaner that the attribute is affecting calling convetion). For our abi I am not sure, we can sysv_abi or something else... Sorry for the typo in your name! Honza Is this ok for you. Cheers, i.A. Kai Tietz | (\_/) This is Bunny. Copy and paste Bunny | (='.'=) into your signature to help him gain | ()_() world domination. -- OneVision Software Entwicklungs GmbH Co. KG Dr.-Leo-Ritter-Straße 9 - 93049 Regensburg Tel: +49.(0)941.78004.0 - Fax: +49.(0)941.78004.489 - www.OneVision.com Commerzbank Regensburg - BLZ 750 400 62 - Konto 6011050 Handelsregister: HRA 6744, Amtsgericht Regensburg Komplementärin: OneVision Software Entwicklungs Verwaltungs GmbH Dr.-Leo-Ritter-Straße 9 ??? 93049 Regensburg Handelsregister: HRB 8932, Amtsgericht Regensburg - Geschäftsführer: Ulrike Döhler, Manuela Kluger
Re: AMD64 ABI compatibility
Windows and GCC ABIs are on x86-64 more different than that (they was historically developed in parallel). GCC 4.3 will support attribute for this calling convention contributed by Kai Tiez and Richard Henderson, but before that there is not much to do... Note: My name is Kai Tietz ;) not Tiez I think, it isn't to hard introducing this attributes to the AMD64 abi's. What names should we use for it? I suggest x86_64_ms and x86_64_linux. For code bridging MS and GNU codebases (such as wine, or lets say, GNU runtime in windows if it ends up with non-MS calling convetions). Then you want to use the attributes to call code from foreign world. x86_64_linux is probably not very exact - we intended the ABI to be generally useful for non-linux or non-GNU system (i.e. specified as System V Application Binary Interface AMD64 Architecture Processor Supplement with GCC as reference implementation). I believe Sparc and other unixes are more or less following it too. For MS I would probably suggest ms_abi (it makes it cleaner that the attribute is affecting calling convetion). For our abi I am not sure, we can sysv_abi or something else... I will prepare an patch for it. For me ms_abi and sysv_abi is fine. Cheers, i.A. Kai Tietz | (\_/) This is Bunny. Copy and paste Bunny | (='.'=) into your signature to help him gain | ()_() world domination. -- OneVision Software Entwicklungs GmbH Co. KG Dr.-Leo-Ritter-Straße 9 - 93049 Regensburg Tel: +49.(0)941.78004.0 - Fax: +49.(0)941.78004.489 - www.OneVision.com Commerzbank Regensburg - BLZ 750 400 62 - Konto 6011050 Handelsregister: HRA 6744, Amtsgericht Regensburg Komplementärin: OneVision Software Entwicklungs Verwaltungs GmbH Dr.-Leo-Ritter-Straße 9 – 93049 Regensburg Handelsregister: HRB 8932, Amtsgericht Regensburg - Geschäftsführer: Ulrike Döhler, Manuela Kluger
Re: AMD64 ABI compatibility
For MS I would probably suggest ms_abi (it makes it cleaner that the attribute is affecting calling convetion). For our abi I am not sure, we can sysv_abi or something else... I will prepare an patch for it. For me ms_abi and sysv_abi is fine. I would say that it is in general very desirable feature for wine programmers and similar projects (I would preffer to have confirmation that they are going to need it however ;). The implementation will be moderately tricky - you will need to keep track of functions calling foreign functions and adjust behaviour of ix86_function_arg_regno_p and friends accordingly. Also the set of call clobbered registers differs. Since MS ABI has fewer of them, calling from SYSV ABI is OK, but in the other direction I guess the call pattern will need to have variants with clobbers of SI/DI. But if you are interested to implement it, you are definitly welcome ;) Honza Cheers, i.A. Kai Tietz | (\_/) This is Bunny. Copy and paste Bunny | (='.'=) into your signature to help him gain | ()_() world domination. -- OneVision Software Entwicklungs GmbH Co. KG Dr.-Leo-Ritter-Straße 9 - 93049 Regensburg Tel: +49.(0)941.78004.0 - Fax: +49.(0)941.78004.489 - www.OneVision.com Commerzbank Regensburg - BLZ 750 400 62 - Konto 6011050 Handelsregister: HRA 6744, Amtsgericht Regensburg Komplementärin: OneVision Software Entwicklungs Verwaltungs GmbH Dr.-Leo-Ritter-Straße 9 ??? 93049 Regensburg Handelsregister: HRB 8932, Amtsgericht Regensburg - Geschäftsführer: Ulrike Döhler, Manuela Kluger
Re: AMD64 ABI compatibility
For MS I would probably suggest ms_abi (it makes it cleaner that the attribute is affecting calling convetion). For our abi I am not sure, we can sysv_abi or something else... I will prepare an patch for it. For me ms_abi and sysv_abi is fine. I would say that it is in general very desirable feature for wine programmers and similar projects (I would preffer to have confirmation that they are going to need it however ;). The implementation will be moderately tricky - you will need to keep track of functions calling foreign functions and adjust behaviour of ix86_function_arg_regno_p and friends accordingly. Also the set of call clobbered registers differs. Since MS ABI has fewer of them, calling from SYSV ABI is OK, but in the other direction I guess the call pattern will need to have variants with clobbers of SI/DI. But if you are interested to implement it, you are definitly welcome ;) Honza I am on that tricky thing ;) I think I need in i386.c an global variable ix86_amd64_abi which helds the the current function abi. This means also that I have to use instead of TARGET_64BIT_MS_ABI this variable. This var may initioalized by init_cumulative_args and the overriden REG_PARM_STACK_SPACE, OUTGOING_REG_PARM_STACK_SPACE, REGPARM_MAX, SSE_REGPARM_MAX, STACK_BOUNDARY, etc. Cheers, i.A. Kai Tietz | (\_/) This is Bunny. Copy and paste Bunny | (='.'=) into your signature to help him gain | ()_() world domination. -- OneVision Software Entwicklungs GmbH Co. KG Dr.-Leo-Ritter-Straße 9 - 93049 Regensburg Tel: +49.(0)941.78004.0 - Fax: +49.(0)941.78004.489 - www.OneVision.com Commerzbank Regensburg - BLZ 750 400 62 - Konto 6011050 Handelsregister: HRA 6744, Amtsgericht Regensburg Komplementärin: OneVision Software Entwicklungs Verwaltungs GmbH Dr.-Leo-Ritter-Straße 9 – 93049 Regensburg Handelsregister: HRB 8932, Amtsgericht Regensburg - Geschäftsführer: Ulrike Döhler, Manuela Kluger
Re: AMD64 ABI compatibility
I am on that tricky thing ;) I think I need in i386.c an global variable ix86_amd64_abi which helds the the current function abi. This means also that I have to use instead of TARGET_64BIT_MS_ABI this variable. This var may initioalized by init_cumulative_args and the overriden REG_PARM_STACK_SPACE, OUTGOING_REG_PARM_STACK_SPACE, REGPARM_MAX, SSE_REGPARM_MAX, STACK_BOUNDARY, etc. In order to get all cases right (ie switching ABIs and calling foreign function), you need more bookkeeping than this. I am just in hurry to catch bus, but I will send you little guide tonight. Honza Cheers, i.A. Kai Tietz | (\_/) This is Bunny. Copy and paste Bunny | (='.'=) into your signature to help him gain | ()_() world domination. -- OneVision Software Entwicklungs GmbH Co. KG Dr.-Leo-Ritter-Straße 9 - 93049 Regensburg Tel: +49.(0)941.78004.0 - Fax: +49.(0)941.78004.489 - www.OneVision.com Commerzbank Regensburg - BLZ 750 400 62 - Konto 6011050 Handelsregister: HRA 6744, Amtsgericht Regensburg Komplementärin: OneVision Software Entwicklungs Verwaltungs GmbH Dr.-Leo-Ritter-Straße 9 ??? 93049 Regensburg Handelsregister: HRB 8932, Amtsgericht Regensburg - Geschäftsführer: Ulrike Döhler, Manuela Kluger
Re: AMD64 ABI compatibility
That's cool! What version would you do the patch for? Apart from wine, I guess mingw should have the biggest need for the MS ABI in order to support AMD64. Nicolas On Jul 10, 2007, at 5:59 , Kai Tietz wrote: Windows and GCC ABIs are on x86-64 more different than that (they was historically developed in parallel). GCC 4.3 will support attribute for this calling convention contributed by Kai Tiez and Richard Henderson, but before that there is not much to do... Note: My name is Kai Tietz ;) not Tiez I think, it isn't to hard introducing this attributes to the AMD64 abi's. What names should we use for it? I suggest x86_64_ms and x86_64_linux. For code bridging MS and GNU codebases (such as wine, or lets say, GNU runtime in windows if it ends up with non-MS calling convetions). Then you want to use the attributes to call code from foreign world. x86_64_linux is probably not very exact - we intended the ABI to be generally useful for non-linux or non-GNU system (i.e. specified as System V Application Binary Interface AMD64 Architecture Processor Supplement with GCC as reference implementation). I believe Sparc and other unixes are more or less following it too. For MS I would probably suggest ms_abi (it makes it cleaner that the attribute is affecting calling convetion). For our abi I am not sure, we can sysv_abi or something else... I will prepare an patch for it. For me ms_abi and sysv_abi is fine. Cheers, i.A. Kai Tietz | (\_/) This is Bunny. Copy and paste Bunny | (='.'=) into your signature to help him gain | ()_() world domination. -- OneVision Software Entwicklungs GmbH Co. KG Dr.-Leo-Ritter-Straße 9 - 93049 Regensburg Tel: +49.(0)941.78004.0 - Fax: +49.(0)941.78004.489 - www.OneVision.com Commerzbank Regensburg - BLZ 750 400 62 - Konto 6011050 Handelsregister: HRA 6744, Amtsgericht Regensburg Komplementärin: OneVision Software Entwicklungs Verwaltungs GmbH Dr.-Leo-Ritter-Straße 9 – 93049 Regensburg Handelsregister: HRB 8932, Amtsgericht Regensburg - Geschäftsführer: Ulrike Döhler, Manuela Kluger
Re: AMD64 ABI compatibility
On 7/10/07, Nicolas Alt [EMAIL PROTECTED] wrote: That's cool! What version would you do the patch for? Apart from wine, I guess mingw should have the biggest need for the MS ABI in order to support AMD64. mingw x86_64 support is already added for 4.3 on the trunk. Thanks, Andrew Pinski
Re: AMD64 ABI compatibility
Ok - so question is if x86_64 is completely implemented already. For our case, especially the MS ABI. Andrew, do you have any knowledge if they introduced a new calling convention and how they named it? Nicolas On Jul 10, 2007, at 13:29 , Andrew Pinski wrote: On 7/10/07, Nicolas Alt [EMAIL PROTECTED] wrote: That's cool! What version would you do the patch for? Apart from wine, I guess mingw should have the biggest need for the MS ABI in order to support AMD64. mingw x86_64 support is already added for 4.3 on the trunk. Thanks, Andrew Pinski
Re: AMD64 ABI compatibility
On 7/10/07, Nicolas Alt [EMAIL PROTECTED] wrote: Ok - so question is if x86_64 is completely implemented already. For our case, especially the MS ABI. Andrew, do you have any knowledge if they introduced a new calling convention and how they named it? It is only implemented for the x86_64-mingw32 target. Thanks, Andrew Pinski
Re: AMD64 ABI compatibility
On Mon, Jul 09, 2007 at 12:48:10PM -0700, Nicolas Alt wrote: Hi! On the AMD64 / x86-64Bit architecture, some arguments of a functions are passed using registers, but there seem to be two different conventions out there. The standard ABI uses 6 registers, but Microsoft compilers use only 4. Because of that, code compiled with gcc cannot call code compiled with a MS compiler without an ugly wrapper. Have there been any efforts to make gcc do function calls the MS way? I guess this would be an important feature for mingw on AMD64. Gcc supports several different ABIs via __attribute__ in the same source file for ia32. I don't see why it shouldn't work on x86-64. H.J.
RE: AMD64 ABI compatibility
On 09 July 2007 20:48, Nicolas Alt wrote: Hi! On the AMD64 / x86-64Bit architecture, some arguments of a functions are passed using registers, but there seem to be two different conventions out there. The standard ABI uses 6 registers, but Microsoft compilers use only 4. Because of that, code compiled with gcc cannot call code compiled with a MS compiler without an ugly wrapper. Have there been any efforts to make gcc do function calls the MS way? I guess this would be an important feature for mingw on AMD64. Does -mregparm=4 do what you want? cheers, DaveK -- Can't think of a witty .sigline today
Re: AMD64 ABI compatibility
Thanks for your reply. The gcc compiler uses %rdi, %rsi, %rdx, %rcx with -mregparm=4, but MS uses %rcx, %rdx, %r8, %r9, so that won't be enough. Also MS requires some space on the stack to be reserved for the 4 regs. Someone has written a wrapper: http://people.freebsd.org/~wpaul/winx64_wrap.S On Jul 9, 2007, at 12:58 , Dave Korn wrote: On 09 July 2007 20:48, Nicolas Alt wrote: Hi! On the AMD64 / x86-64Bit architecture, some arguments of a functions are passed using registers, but there seem to be two different conventions out there. The standard ABI uses 6 registers, but Microsoft compilers use only 4. Because of that, code compiled with gcc cannot call code compiled with a MS compiler without an ugly wrapper. Have there been any efforts to make gcc do function calls the MS way? I guess this would be an important feature for mingw on AMD64. Does -mregparm=4 do what you want? cheers, DaveK -- Can't think of a witty .sigline today
Re: AMD64 ABI compatibility
Yea, __attribute__ should be the way to go - however, I have not found any attribute like msabi or so. It still needs to be implemented in the compiler. Most of the ia32 attributes are ignored anyway. On Jul 9, 2007, at 12:55 , H.J. Lu wrote: On Mon, Jul 09, 2007 at 12:48:10PM -0700, Nicolas Alt wrote: Hi! On the AMD64 / x86-64Bit architecture, some arguments of a functions are passed using registers, but there seem to be two different conventions out there. The standard ABI uses 6 registers, but Microsoft compilers use only 4. Because of that, code compiled with gcc cannot call code compiled with a MS compiler without an ugly wrapper. Have there been any efforts to make gcc do function calls the MS way? I guess this would be an important feature for mingw on AMD64. Gcc supports several different ABIs via __attribute__ in the same source file for ia32. I don't see why it shouldn't work on x86-64. H.J.
