When we've built ECL without dynamic VV, the preprocessor define VM was
referenced in the produced header before it was defined. That lead to an error.
According to the CLHS:
> If a DEFCLASS form appears as a top level form, [...] the compiler
must make the class definition available to be returned by FIND-CLASS
when its environment argument is a value received as the environment
parameter of a macro.
We already store type definitions in the compiler environment, so we
can just reuse that.
While The metaobject protocol doesn't specify what happens when
compiling DEFCLASS, only what happens when executing it (see
https://franz.com/support/documentation/mop/concepts.html#compile-file),
real life software breaks when we try to create a full class object at
compile time. Therefore, we just create a dummy forward-referenced
class object which contains nothing more than a name.
We can't pass compound function types (i.e. function types which
include argument and return types) to TYPEP. At some places, this was
already handled but not everywhere. A new function CMP-TYPEP is
introduced to handle this. At any place where a user-supplied type is
checked at compile time, we need to use CMP-TYPEP instead of TYPEP.
Dead code eliminiation often happens for automatically generated code,
so this leads to many false positives for code that doesn't have any
style issues.
Moreover, the combination of compiler-note and style-warning is
handled badly by asdf. By default, we don't display compiler-notes but
asdf catches style-warnings to display a notice that a style-warning
has been emitted which is confusing since no warning has been printed.
There were a number of bugs here:
- REAL was returned even for complex exponents
- The special case of exponent=0 wasn't handled correctly
- In some cases, EXPT could return integer or rational results but the
type propagator would always assume that coercion to floating point
was happening.
We deprecate the function si_ihs_env in favor of more explicit si_ihs_lex and
si_ihs_lcl, but the former is left for backward compatibility with SLIME/SLYNK
because they call it to query the environment to add locals to the backtrace.
Since ~recently we store local variables in the bytevm on the stack. Also, the
native comipler under specified debug options, stores locals in ihs, but it has
nothing to do with the lexical environment. So it feels justified to push both
to a separate field.
It may seem like this proclamation is invalid sincd !346, but the divergence
happens much earlier. 8c0314022c introduces a
feature where c-compiled code can also add debug information, and in that case
the environment is a vector, so the proclamation back then should be:
(proclamation si:ihs-env (si::index) (or list vector))
Later when we've changed the representation, it should be changed to
(proclamation si:ihs-env (si::index) (or null vector))
Where NULL denotes "no lexical environment".
(DEFCONFIG *LD-SHARED-FLAGS*) was called without a value when dlopen was not
defined, that lead to error when destructuring. We put there "" instead now.
Previously, calling COMPILE during cross compilation always failed due
to trying to load a shared object compiled for the wrong architecture.
We now temporarily switch back to the host configuration, compile and
load our shared object, and then go on with the target config.
Cross compilation of ECL itself:
- The windres program comes with the usual cross compilation target
prefixes, use AC_CHECK_TOOL to select the right one.
- For c::update-compiler-features, we need to check the features of the
host system instead of the target because that determines the
executable prefix of the ecl_min stub.
Cross compilation of user code: We just have to replace some read time
conditionals by runtime checks.
Further notes on Windows cross compilation using mingw:
- Our old copy of libgmp doesn't work, one needs to update that before
compiling.
- ASDF fails to compile unless XDG_CACHE_HOME is set (it tries and
fails to find a Windows cache directory if XDG_CACHE_HOME is empty).
- The `windres` program may be located in a separate package from the
mingw compiler. On debian, I had to install binutils-mingw-w64 and
gcc-mingw-w64.
This allows us to switch out the proclamations when cross-compiling so
that target specific functions are declared correctly.
This was a problem for cross compilation with mismatching thread
support, so we can now allow that.
Due to the recent introduction of cross compilation features,
*cmp-env* has to contain type information throughout the entire
compilation (not only while we are compiling a form) so that (typep x
type *cmp-env*) works correctly. Therefore, we can't set *cmp-env* to
nil initially as we did previously. Instead, we set *cmp-env*
to *cmp-env-root* initially.
A host compiler without complex float support still needs to be able
to emit C instructions for complex float. In this case, the host
doesn't define si::complex-{single/double/long}-float types, so we
need to replace those by types which all variants of ECL understand.
Moreover, functions for emitting C code dealing with complex floats
must be present even if the host doesn't support complex floats
natively.
Deciding whether to emit these instructions is implemented either by
explicit checks for *complex-float* or automatically as the compiler
will not create :c{s/d/l}float locations for a target without complex
float support (this is decided at runtime based on the contents
of *machine*).
The procedure works as follows. First, cross compile ECL itself. In
this step, we dump the configuration of the compiler. This
configuration can then be later restored to put the host compiler into
cross compilation mode using a new option to WITH-COMPILATION-UNIT.
The following changes to the public interface are introduced:
- WITH-COMPILATION-UNIT now takes a new :target keyword
- New functions C:WRITE-TARGET-INFO, C:READ-TARGET-INFO to dump and
restore the config
- The environment parameters to TYPEP and SUBTYPEP are no longer
unused. User macros can query type relationships in the target
environment using these parameters.
Internal changes in the compiler include:
- Target dependent variables in the compiler are defined using a new
DEFCONFIG macro. C:WRITE-TARGET-INFO simply writes the value of
these variables to a file.
- The distinction between target types and host types already exists
in the compiler. In this commit, we just register the target types in
the compiler environment when we change the compiler configuration.
Fixes a regression introduced in commit
816c08340b. After the changes in that
commit, c1forms of name variable can denote constants as well.
Since we are now more aggressive with inlining constant access, we
have to fix a bad defconstant definition in clos/boot.lsp as well (the
new definition makes sure that the compile-time and load-time
evaluations of the constant are eql).
It seems that some variables were rebound also in cmptype-arith.lsp -- to avoid
potential inconsistency we abstract away bindings as WITH-TYPE-DTABASE.
The deftype expansion functions now take two parameters, the type
argument and an environment. More precisely, for an atomic type 'x the
type argument for the expansion function is given by '(x) while for a
non-atomic type '(x y z) it is given by '(x y z). This also fixes the
value of &whole parameters in deftype lambda lists. The new behaviour
is consistent with SBCL and CCL.
Fixes#750
This commit replaces capturing whole LEX with an explicit vector of closed
variables. We introduce a set of additional opcodes that deal with closed
entities. Locals are referred as lcl and closed variables as lex.
When we were compiling bytecodes with LABELS, the function SET-CLOSURE-ENV
exhibited infinite recursion by adding the record as FLET. C.f test "cmp.0100".
Constant arguments for the dimensions were not handled correctly. The
valid-array-index function was lost in a refactor some time ago.
Moreover, we need to check all of the conditions on the
dimensions (limits on rank, dimension and total size) using an AND
statement instead of checking only the first condition using OR.
Simply call mkdir and ignore EEXIST errors to prevent race conditions
when two processes try to create a directory at the same time. Also
avoids a redundant syscall since by not calling si::file-kind, so this
should be slightly faster.
These are badly optimized by C compilers (even single use static
functions are not inlined by both gcc and clang), so instead of
generating a separate variadic entrypoint just generate one single
entrypoint with C compatible signature.
The presence of setjmp calls in function bodies means that some
function arguments have to be volatile. However, this doesn't apply to
variadic entrypoints which never include setjmp calls. Thus,
set *volatile* to be empty before writing out the header.
Only applies for COMPILE calls where the name of a setf function
definition will not be equal under the EQ test to the name of the same
function at a later call. Thus, we have to use EQUAL to find those
names in the vv array.
For C compatible variadic dispatch, the compiler now generates two
entrypoints for variadic functions. An entrypoint with specialized
signature that is used for direct C calls from the same file and an
entrypoint with generic signature that implements the variadic to
variadic dispatch, i.e. checking the number of arguments and then
calling the specialized entrypoint.
This approach is faster than using the wrapper functions in
variadic_dispatch_table. The reasons are threefold: we save a call to
ecl_process_env(), we don't need a call through a function pointer but
instead use a direct call to the specialized entrypoint and we emit
better code to deal with required arguments since the number of those
are known.
Moreover, for functions with optional arguments the new approach is
less stack hungry since we can allocate an array of size smaller than
ECL_C_ARGUMENTS_LIMIT to store the arguments.
