Nonstandard function attributes

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Nonstandard function attributes

Dirk Zoller
Hello,

with the advent of gcc-2.95 the wonderful world of funny nonstandard
function attributes has finally reached the intel-based Unices (which
are the platforms I happen to be interested in.)

For example one can now specify that the called function clears the
stack and that parameters are to be passed in registers. This is nothing
new for Borland-C and MS-C users.

To illustrate the effect of such declarations, I'll show some of the
inner workings of the Lua to C API below with and without such
nonstandard declarations.

Both the called function and the function call are shorter. Especially
the lua C-API takes a lot of function calls and programs which massively
do lua_getparam, lua_pushthings and lua_dosomethingwiththepushedstuff
may compile to significantly better code.

Also lua internally employs a C programming style with lots of tiny
functions. Good style but expensive when all the time parameters are
pushed to and removed from the hardware stack.

On the other hand, while useful, such declarations are extremely ugly.
One can hide some of the ugliness in macros but not all.

What do you think, would it be worthwile to introduce this ugliness into
Lua source? Or at maybe only into the C-API?


Regards

Dirk Zoller

----------------------------------------------------------------------------
Source, multistate lua:
----------------------------------------------------------------------------

static lua_Type normalized_type (lua_State *lua_state,TObject *o)
{
  lua_Type t = ttype(o);
  switch (t) {
    case LUA_T_PMARK:
      return LUA_T_PROTO;
    case LUA_T_CMARK:
      return LUA_T_CPROTO;
    case LUA_T_CLMARK:
      return LUA_T_CLOSURE;
    default:
      return t;
  }
}

static void set_normalized (lua_State *lua_state,TObject *d, TObject *s)
{
  d->value = s->value;
  d->ttype = normalized_type(L,s);
}


----------------------------------------------------------------------------
Without nonstandard attributes:
----------------------------------------------------------------------------

normalized_type:
	movl 8(%esp),%eax
	movl (%eax),%eax
	cmpl $-9,%eax
	je .L7
	jg .L12
	cmpl $-10,%eax
	je .L8
	ret
	.p2align 4,,7
.L12:
	cmpl $-8,%eax
	je .L9
	ret
	.p2align 4,,7
.L7:
	movl $-4,%eax
	ret
	.p2align 4,,7
.L8:
	movl $-5,%eax
	ret
	.p2align 4,,7
.L9:
	movl $-7,%eax
	ret
.Lfe2:
	.size	 normalized_type,.Lfe2-normalized_type
	.align 4
	.type	 set_normalized,@function
set_normalized:
	pushl %esi
	pushl %ebx
	movl 20(%esp),%ecx
	movl 12(%esp),%esi
	movl 16(%esp),%ebx
	movl 4(%ecx),%eax
	movl 8(%ecx),%edx
	movl %eax,4(%ebx)
	movl %edx,8(%ebx)
	pushl %ecx
	pushl %esi
	call normalized_type
	movl %eax,(%ebx)
	addl $8,%esp
	popl %ebx
	popl %esi
	ret


----------------------------------------------------------------------------
With __attribute(__stdcall__,__regparm__(3))
----------------------------------------------------------------------------

normalized_type__FP9lua_StateP7TObject:
	movl (%edx),%eax
	cmpl $-9,%eax
	je .L8
	jg .L13
	cmpl $-10,%eax
	je .L9
	ret
	.p2align 4,,7
.L13:
	cmpl $-8,%eax
	je .L10
	ret
	.p2align 4,,7
.L8:
	movl $-4,%eax
	ret
	.p2align 4,,7
.L9:
	movl $-5,%eax
	ret
	.p2align 4,,7
.L10:
	movl $-7,%eax
	ret
.Lfe2:
	.size	
normalized_type__FP9lua_StateP7TObject,.Lfe2-normalized_type__FP9lua_StateP7TObject
	.align 4
	.type	 set_normalized__FP9lua_StateP7TObjectT1,@function
set_normalized__FP9lua_StateP7TObjectT1:
	pushl %esi
	movl %eax,%esi
	movl 4(%ecx),%eax
	pushl %ebx
	movl %edx,%ebx
	movl 8(%ecx),%edx
	movl %eax,4(%ebx)
	movl %edx,8(%ebx)
	movl %ecx,%edx
	movl %esi,%eax
	call normalized_type__FP9lua_StateP7TObject
	movl %eax,(%ebx)
	popl %ebx
	popl %esi
	ret



-- 
Dirk Zoller <[hidden email]>

Reply | Threaded
Open this post in threaded view
|

Re: Nonstandard function attributes

Luiz Henrique de Figueiredo
>From [hidden email] Sat Aug  7 08:42:51 1999
>From: Dirk Zoller <[hidden email]>

>Also lua internally employs a C programming style with lots of tiny
>functions. Good style but expensive when all the time parameters are
>pushed to and removed from the hardware stack.

how "expensive"? is speed really a problem in your application?

>On the other hand, while useful, such declarations are extremely ugly.

plus, they're not ANSI C. or are they #pragmas?

>What do you think, would it be worthwile to introduce this ugliness into
>Lua source? Or at maybe only into the C-API?

sorry, no. I think we'll stick to ANSI C.
but how about if you posted the changes or, beter still, a script?
--lhf