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.
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.
The function disassemble will end up in the backend too eventually, although for
now it is defined in cmpmain. Recently we've moved backend-specific variables to
the code generation pass, but disassemble still relies on that environment.
The propagator for FSET did not descend to the function object while the
propagator for LOCALS did (that was inconsistent). Also cmpmain called
P1PROPAGATE on *LOCAL-FUNS* before the second pass so that was no-op.
Previously we've carries the "assumption" list through all calls, but said
assumption list was never used to make any decisions (and we had numerous
assertions that it must be null at various places).
The assumption list made the code less readable because it intorduced numerous
loops and multiple-value-bind calls just to maintain it. Removal introduces no
known regressions.
Use proper package accessors instead. This was mostly already done. Removal of
package imports make it easier to tell when symbols do not belong to cmp.
Split up the options into additional flags for the linker and
additional libraries.
Quoting from issue #636:
> Here's an example, attempting to link one object file named
example.o into an executable named example. Libcrypto here is
superfluous and should be removed by --as-needed:
```
LDFLAGS="-Wl,--as-needed"
LIBS="-lcrypto"
gcc ${LDFLAGS} ${LIBS} example.o -o example # doesn't link libcrypto!
gcc example.o ${LDFLAGS} ${LIBS} -o example # doesn't honor --as-needed!
gcc ${LDFLAGS} example.o ${LIBS} -o example # works great!
```
> In short, the placement of your -l<foo> flags differs from that of
all the other linker flags. Since ECL is only providing one big
variable ld-flags for all of the linker flags, there's no correct
way to pass in options like --as-needed and -l<foo> at the same
time.
Fixes#636.
On Unix, pathnames are converted into the default encoding specified
by ext:*default-external-format* and back. On Windows, the operating
system already gives us utf16 encoded pathnames, so we use those.
ecl_namestring with ECL_NAMESTRING_FORCE_BASE_STRING encodes with the
specified encoding. Decoding is handled individually in the filesystem
functions.
Includes a minor refactor of list_directory, changing the
PARSE_DIRECTORY_ENTRY macro into an inline function.
Closes#609, #549.
The type propagation is invoked with a function compiler-pass/propagate-types
before the compiler-pass2. Previously the type propagation was invoked in
ctop-write.
- separate passes
The separation is not fine-grained but is a good starting point for further
cleanup. This is a preliminary requirement for multiple backends.
- use uninternet symbol in the package definition
- remove "execute" permission from all files
- remove a few unused functions
- rearrange loaded files
- less verbose compiler
Don't print "End of pass 1." message. This doesn't provide any valuable
information to the programmer.
Improves compilation speed for single functions by about 40-50
percent. Precompiled headers are specific to the compiler version and
options in use. Due to this, we regenerate the header whenever the
compiler configuration changes.
This behaviour makes more sense, since the ANSI standard mandates
that disassemble should compile an interpreted function before
displaying the output (our own documentation even says so).
Also fixes disassemble for closures.
After a call to ext:install-c-compiler while the bytecodes compiler
is installed, compile-file and compile-file-pathname still point
to bc-compile-file and bc-compile-file-pathname. Reported and
fixed by gitlab user pouar. Fixes#444.
Signal an error for compilation of cclosures. Allow for
compilation of bclosures over macros, functions and variables.
Macros are simply added to the compiler environment. For functions
and variables we enclose the definition of the closure in
appropiate let/flet forms, e.g. for `(lambda () (fun var))'
closing over the function `fun' and variable `var':
(let ((var ...))
(flet ((fun (x) ...))
(lambda () (fun var))))
Closures over tags and blocks are not implemented and will signal
an error during compilation.
