| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
This can be used to define some generic (polymorphic) builtin
with a signature like:
<name>(int)
<name>(T, T)
<name>(int, T)
<name>(int, T, long, T, ... T)
where T is some integer type which will be instantiated at each call.
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
Make declare_builtins() extern so that it can be used from other files.
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
Till now, 2 tables are used to initialize builtin functions:
* an older, small one, without type information, used to set
a symbol_op to evaluate and/or expand the ones that have
some associated behaviour.
* a newer and bigger one which only contains what is effectively
the prototype for these builtins in order to avoid warnings
about undeclared functions.
It's kinda annoying to have 2 tables for this, even more so
because most entries in the first table also need to be in the
second one (for arguments type and number checking).
Fix this by:
* adding a field in the second table for the symbol_op
* merging or moving the entries in the first table into
the second one.
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
The curent way to declare the builtins is not by using a table
but via a (variadic) function call, one for each builtin.
A table is preferable but a complication for doing this
is that some elements are not constant. For example, 'size_t_ctype'
is dynamically set in the early steps of the type initialization.
Doing a series of function calls allowed to circumvent this.
Fix this by:
* Using a constant temporary alias for non-constant entries. It's the
value of these alias that will be used when registering the builtins.
* using a table to declare the builtin functions.
Note: the motivation for doing this is to be able to add sub-tables
for the arch-specific builtins (and use the same mechanism
as for the main table).
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
