ecl_alloc_object, ecl_free_object
ecl_alloc, ecl_alloc_manual, ecl_alloc_atomic, ecl_dealloc
Moreover move all top-level ops to memory.d so they are not reliant on mem_gc.
The stubbed allocator uses manual memory managament for all ops.
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.
This is needed to allow for cross compiling from a compiler with a
different set of configure options (e.g. compiling for a target which
doesn't support complex floats from a host which does).
- we did not distinguish between classes that had no slots and classes that
had no been iniutialized - that led to incorrect class stamps
- structures had no initial class stamp matching their structure
- structures when slot names chagned had their stamp increased despite not
really changing
Slot definitions are no longer a signature, but they are still needed
to update obsolete instances. Reader function name is also changed to
SI:INSTANCE-SLOTDS. SI:INSTANCE-SIG-SET name does not change, because
it sets both SLOTDS and the STAMP.
We should call make-instances-obsolete from finalize-inheritance if we
want to be conforming, because user may have added their own auxiliary
methods.
This change while being last in a serie of commits was locally the
first change which solved problems. It will enable us to implement the
fast generic dispatch after the release.
It helps to determine whether the instance needs to be updated for a
class after redefinition. Currently it is done by comparing the
signature with the instance's class slots.
Many parts of the source code were bent backward to support builds
without long floats which are always present given we depend expect
c99 compiler.
The corresponding C macros (ECL_LONG_FLOAT) and the *feature*
entry (:long-float) are marked as deprecated in the documentation.
cl_type_of: give better results for (type-of <complex>)
Instead of simply returning complex we return:
(complex real)
when code is built without complex float support, and otherwise
(complex rational)
(complex single-float)
(complex double-float)
(complex long-float)
New functions:
- ecl_to_csfloat
- ecl_to_cdfloat
- ecl_to_clfloat
What has changed:
- new types si:complex-float, si:complex-single-float,
si:complex-double-float and si:complex-long-float
- new builtin classes long-float (for completness) and
si:complex-float
- new internal function si:complex-float and si:complex-float-p for
constructing complex floats (both arguments must be of the same
float type) and a type predicate
- printer for new types (right now it conses, see below)
- a new feature :complex-float
- a new type is recognized as a type disjoint of complex and real
- cleanup: +built-in-type-list+: remove some redundancy
For instance instread of saying
(real (or integer single-float double-float ratio))
We say
(real (or integer float ratio))
etc.
Flaws which will be fixed in upcoming commits:
- complex-float hierarchy is independent of the complex hierarchy
- ecl_make_complex_float could be replaced by _ecl_make_complex_*float
- write_complex_float allocates new objects for printing
- write_complex_float does print unreadable object
- math dispatchers doesn't recognize the object
Testing things out:
> (si:complex-float 0.0d0 0.0d0)
; #<CF(0.0d0 0.0d0)>
> (si:complex-float 0.0d0 0.0s0) ; signals type error
> (+ (si:complex-float 0.0d0 0.0d0) 1) ; signals type error
lisp runtime: make si_complex-float a subtype of a number.
We support both compare-and-swap and fetch-and-add (via
atomic-incf/decf) on the most common places and define an
extension interface for compare-and-swap similiar to the one in
SBCL.
These changes introduce new dependencies on the libatomic_ops
macros AO_fetch_compare_and_swap and AO_fetch_and_add.
