1
Fork 0
mirror of https://git.savannah.gnu.org/git/guile.git synced 2025-06-21 19:20:21 +02:00

Make it clear stdarg like abstraction is not supported.

* include/lightning.h, include/lightning/jit_private.h,
	lib/jit_arm.c, lib/jit_mips.c, lib/jit_ppc.c, lib/jit_x86.c,
	lib/lightning.c: Make jit_ellipsis implementation not
	backend specific. It is not intended to handle va_list
	like objects at runtime, as jit_arg* and jit_getarg*
	return constant values resolved at parse time, so, effectively
	it is not possible to create printf like jit functions, as
	there is no va_start, va_arg, va_end, etc, abstraction. This
	limitation should be kept for the sake of making new ports
	easier.
This commit is contained in:
pcpa 2012-12-14 15:21:39 -02:00
parent 074056499f
commit 03559bb8cc
8 changed files with 67 additions and 45 deletions

View file

@ -725,10 +725,34 @@ void
_jit_prepare(jit_state_t *_jit)
{
assert(_jit->function);
_jit->function->call.kind = jit_call_default;
_jit->function->call.call = jit_call_default;
_jit->function->call.argi =
_jit->function->call.argf =
_jit->function->call.size = 0;
_jit->prepare = 1;
}
/* If declaring a jit function as varargs, in most backends it does
* not change anything. Currently only exception is arm backend, that
* if running in hardware float abi, switches to software float abi
* if "self" function is varargs. Otherwise, there is no logic to
* handle va_list like objects that need to parse runtime state, and
* that is mainly because jit_arg* and jit_getarg* work only with
* constants values, and one must not expect them to be handled at
* runtime, they are parsed only once (same applies to jit_allocai,
* that has no jit_allocar counterpart).
*/
void
_jit_ellipsis(jit_state_t *_jit)
{
if (_jit->prepare) {
assert(!_jit->function->call.call & jit_call_varargs);
_jit->function->call.call |= jit_call_varargs;
}
else {
assert(!_jit->function->self.call & jit_call_varargs);
_jit->function->self.call |= jit_call_varargs;
}
}
void