On Fri, Dec 08, 2006 at 11:33:04AM -0500, Jeff Dike wrote:
> On Fri, Dec 08, 2006 at 01:59:28PM +0100, Adrian Bunk wrote:
> > UML on i386 is now the only case where fastcall/FASTCALL is not a noop.
>
> If i386 doesn't use it any more, then UML shouldn't either. The only reason
> there's support
On Fri, Dec 08, 2006 at 01:59:28PM +0100, Adrian Bunk wrote:
> UML on i386 is now the only case where fastcall/FASTCALL is not a noop.
If i386 doesn't use it any more, then UML shouldn't either. The only reason
there's support for it in UML is that I was copying i386.
UML on i386 is now the only case where fastcall/FASTCALL is not a noop.
There are two use cases for fastcall/FASTCALL in UML on i386:
1. optimization for C code
A faster calling convention is used for the functions annotated this way.
2. interfacing with assembler code
But include/asm-um
UML on i386 is now the only case where fastcall/FASTCALL is not a noop.
There are two use cases for fastcall/FASTCALL in UML on i386:
1. optimization for C code
A faster calling convention is used for the functions annotated this way.
2. interfacing with assembler code
But include/asm-um
On Fri, Dec 08, 2006 at 01:59:28PM +0100, Adrian Bunk wrote:
UML on i386 is now the only case where fastcall/FASTCALL is not a noop.
If i386 doesn't use it any more, then UML shouldn't either. The only reason
there's support for it in UML is that I was copying i386.
On Fri, Dec 08, 2006 at 11:33:04AM -0500, Jeff Dike wrote:
On Fri, Dec 08, 2006 at 01:59:28PM +0100, Adrian Bunk wrote:
UML on i386 is now the only case where fastcall/FASTCALL is not a noop.
If i386 doesn't use it any more, then UML shouldn't either. The only reason
there's support for it
6 matches
Mail list logo
