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
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 A
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 :) Th
> 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. Th
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
i
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 ss
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.
> 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
> > > m
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 fo
>
> 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 f
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
>
> >
> > 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 over
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-min
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 <[EMA
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
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
historicall
>
> 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
> R
> > >
> > > 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 sa
> >
> > 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 ge
> > > 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 nam
> > 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 Tiet
> > 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 com
> 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
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, Nico
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_wra
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 th
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 u
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 co
28 matches
Mail list logo