Hi,
On Thu, 12 Oct 2006, Kai Tietz wrote:
> thanks for description. I wasn't aware, that the upper 32 bits are
> zeroed. Does this means that even the stack has to be in the first 4 Gb,
> too.
Why should it? I.e. no, it doesn't have to.
> Or does this mov instruction does a sign-extention.
Hello Michael,
thanks for description. I wasn't aware, that the upper 32 bits are zeroed.
Does this means that even the stack has to be in the first 4 Gb, too. Or
does this mov instruction does a sign-extention.
Best regards,
i.A. Kai Tietz
Hi,
On Wed, 11 Oct 2006, Kai Tietz wrote:
> > -mcmodel=small'
> > Generate code for the small code model: the program and its
> > symbols must be linked in the lower 2 GB of the address space.
> > Pointers are 64 bits. Programs can be statically or dynamically
> > linked. This is the de
Hello Andrew,
> -mcmodel=small'
> Generate code for the small code model: the program and its
> symbols must be linked in the lower 2 GB of the address space.
> Pointers are 64 bits. Programs can be statically or dynamically
> linked. This is the default code model.
You are right, the d
Kai Tietz writes:
> I am currently on to build the gcc target support for x86_64-pc-mingw64.
> While this porting I found a strange register truncation, I do not believe
> it is valid. For the c code:
>
> int foo(char *,...);
> int doo(char *h) { return foo("abc ",h); }
>
Hello,
I am currently on to build the gcc target support for x86_64-pc-mingw64.
While this porting I found a strange register truncation, I do not believe
it is valid. For the c code:
int foo(char *,...);
int doo(char *h) { return foo("abc ",h); }
compiled result ->
.f
