mirror of
git://git.code.sf.net/p/sbcl/sbcl
synced 2026-09-10 07:26:40 -04:00
* Make two passes: first, compute live _sets_, second, order
them to stacks;
* new VOP: %%NIP-VALUES, removing dead UVL from the middle of
the stack (currently implemented only on X86).
195 lines
8.8 KiB
Plaintext
195 lines
8.8 KiB
Plaintext
for the stack branch:
|
|
* comments
|
|
* profile
|
|
** more efficient implementation
|
|
* support for non-x86 architectures
|
|
|
|
|
|
for early 0.8.x:
|
|
|
|
* test file reworking
|
|
** non-x86 ports now pass irrat.pure.lisp
|
|
** ports with less than 256Mb of heap (sparc, ppc and mips)
|
|
now don't fail bit-vector.impure-cload.lisp
|
|
* faster bootstrapping (both make.sh and slam.sh)
|
|
** added mechanisms for automatically finding dead code, and
|
|
used them to remove dead code
|
|
** moved stuff from warm init into cold init where possible
|
|
(so that slam.sh will run faster and also just because
|
|
ideally everything would be in cold init)
|
|
** profiled and tweaked
|
|
* fixed (TRACE :REPORT PROFILE ...) interface to profiling
|
|
* more EVAL/EVAL-WHEN/%COMPILE/DEFUN/DEFSTRUCT cleanup:
|
|
** made %COMPILE understand magicality of DEFUN FOO
|
|
w.r.t. e.g. preexisting inlineness of FOO
|
|
** used %COMPILE where COMPILE-TOP-LEVEL used to be used
|
|
** removed now-redundant COMPILE-TOP-LEVEL and
|
|
FUNCTIONAL-KIND=:TOP-LEVEL stuff from the compiler
|
|
** (ideally, but perhaps too hard, given what I've discovered
|
|
about the godawful internals of function debug names):
|
|
made FUNCTION-NAME logic work on closures, so that
|
|
various public functions like CL:PACKAGEP which
|
|
are now implemented as closures (because
|
|
they're structure slot accessors) won't be so
|
|
nasty in the debugger
|
|
* outstanding embarrassments
|
|
** :IGNORE-ERRORS-P cruft in stems-and-flags.lisp-expr. (It's
|
|
reasonable to support this as a crutch when initially
|
|
bootstrapping from balky xc hosts with their own
|
|
idiosyncratic ideas of what merits FAILURE-P, but it's
|
|
embarrassing to have to use it when bootstrapping
|
|
under SBCL!),
|
|
* fixups now feasible because of pre7 changes
|
|
** ANSIfied DECLAIM INLINE stuff (deprecating MAYBE-INLINE,
|
|
including e.g. on the man page)
|
|
** (maybe) allow INLINE of a recursive function, so that the
|
|
body is inlined once
|
|
* miscellaneous simple refactoring
|
|
* belated renaming:
|
|
** renamed %PRIMITIVE to %VOP
|
|
** A few hundred things named FN and FCN should be
|
|
named FUN (but maybe not while drichards is
|
|
working on a Windows port).
|
|
* These days ANSI C has inline functions, so..
|
|
** redid many cpp macros as inline functions:
|
|
HeaderValue, Pointerp, CEILING, ALIGNED_SIZE,
|
|
GET_FREE_POINTER, SET_FREE_POINTER,
|
|
GET_GC_TRIGGER, SET_GC_TRIGGER, GetBSP, SetBSP,
|
|
os_trunc_foo(), os_round_up_foo()
|
|
** removed various avoid-evaluating-C-macro-arg-twice
|
|
cruft
|
|
* Either get rid of or at least rework the fdefinition/encapsulation
|
|
system so that (SYMBOL-FUNCTION 'FOO) is identically equal to
|
|
(FDEFINITION 'FOO).
|
|
* Make the system sources understandable to the system, so that
|
|
searching for sources doesn't error out quite so often
|
|
(e.g. in error handlers)
|
|
** provided a location-independent way of referring to source
|
|
files in the target image, maybe a SYS: logical
|
|
pathname, and made the build system respect this.
|
|
** provided a suitable readtable for reading in the source
|
|
files when necessary, and a mechanism for activating
|
|
this readtable rather than the standard one.
|
|
|
|
=======================================================================
|
|
for 0.9:
|
|
|
|
[ note: much of the below refers to preparation for merging SB-PCL:FOO
|
|
and CL:FOO. However, it turned out to be surprisingly
|
|
straightforward to do this notional end goal without doing many of
|
|
the preparatory operations. That doesn't mean that plenty of the
|
|
goals below aren't worthwhile, but the motivation is somewhat
|
|
different. ]
|
|
|
|
* refactored in preparation for moving CLOS into cold init and merging
|
|
SB-PCL:FOO with CL:FOO (for FOO=CLASS, FOO=CLASS-OF, etc.)
|
|
** systematized support for MOP (more regression tests, maybe)
|
|
to try to make sure things don't get mislaid in the
|
|
upcoming CLOS restructuring
|
|
** extracted type system (and maybe CLASSOIDs) from SB-KERNEL
|
|
into new SB-TYPE package
|
|
** reimplemented GENERIC-FUNCTION as a primitive object (or
|
|
maybe made SB-MOP:FUNCALLABLE-STANDARD-OBJECT the
|
|
primitive object, and then let GENERIC-FUNCTIONs
|
|
inherit from that) instead of structures with
|
|
:ALTERNATE-METACLASS and funcallableness. Now
|
|
FUNCALLABLE-INSTANCE can go away. (And now the new
|
|
funcallable primitive objects need to go into
|
|
collections like *FUN-HEADER-WIDETAGS* where
|
|
FUNCALLABLE-INSTANCE objects used to be.)
|
|
** reimplemented CONDITIONs as primitive objects instead of
|
|
structures with :ALTERNATE-METACLASS. Now (between
|
|
this and the change to GENERIC-FUNCTIONs)
|
|
DEFSTRUCT :ALTERNATE-METACLASS can go away.
|
|
** (maybe) Now INSTANCE_POINTER_LOWTAG can become just
|
|
STRUCTURE_POINTER_LOWTAG, and the concept of
|
|
SB-KERNEL:INSTANCE (including INSTANCEP,
|
|
(SPECIFIER-TYPE 'INSTANCE), etc.) can go away.
|
|
* moved CLOS into cold init, in order to allow CLOS to be used in the
|
|
implementation of the core system (e.g. the type system and the
|
|
compiler) and in order to support merger of CL:CLASS with
|
|
SB-PCL:CLASS
|
|
* (maybe) eliminated warm init altogether in favor of cold init
|
|
* (maybe, especially if warm init can be eliminated) rationalized
|
|
the build process, fixing miscellaneous pre-0.5.0 stuff that's
|
|
transparently not the right thing
|
|
** removed separate build directories, now just building in
|
|
place with .sbclcoldfasl extensions
|
|
* (maybe) more refactoring in preparation for merging SB-PCL:FOO
|
|
into CL:FOO: reimplemented type system OO dispatch
|
|
(!DEFINE-TYPE-METHOD, etc.) in terms of CLOS OO dispatch
|
|
* added some automatic tests for basic binary compatibility, in hopes
|
|
that it might be practical to maintain binary compatibility
|
|
between minor maintenance releases on the stable branch (but no
|
|
promises, sorry, since I've never tried to do this before, and
|
|
have no idea how much of a pain this'll be)
|
|
========================================================================
|
|
for 1.0 (fixes of lower priority which I'd nonetheless be embarrassed
|
|
to leave unfixed in 1.0):
|
|
* all too many BUGS entries and FIXMEs
|
|
=======================================================================
|
|
other priorities, no particular time:
|
|
|
|
* bug fixes, especially really annoying bugs (ANSI or not) and any
|
|
ANSI bugs (i.e. not just bugs in extras like the debugger or
|
|
"declarations are assertions", but violations of the standard)
|
|
* better communication with the outside world (scratching WHN's
|
|
personal itch): I don't want socket-level stuff so much as I
|
|
want RPC-level or higher (CORBA?) interfaces and (possibly
|
|
through RPC or CORBA) GUI support
|
|
* Especially when ldb is not compiled in, the default "assertion failed"
|
|
behaviour in many parts of the runtime is unfriendly. It may
|
|
be appropriate to look at some of these and see if they can be
|
|
handled in some less abrupt way than aborting
|
|
=======================================================================
|
|
important but out of scope (for WHN, anyway: Patches from other people
|
|
are still welcome!) until after 1.0:
|
|
* DYNAMIC-EXTENT
|
|
* sadly deteriorated support for ANSI-style block compilation
|
|
(static linking of DEFUNs within a single file or
|
|
WITH-COMPILATION-UNIT)
|
|
* various GC issues (exuberant cut-and-paste coding,
|
|
possibly dangerously over-conservative handling
|
|
of neighbors of function objects, general GC efficiency)
|
|
* package issues other than SB!TYPE, SB!MOP, and dead exported
|
|
symbols
|
|
* Any systematic effort to fix compiler consistency checks is
|
|
out of scope. (However, it still might be possible to
|
|
determine that some or all of them are hopelessly stale
|
|
and delete them.)
|
|
=======================================================================
|
|
other known issues with no particular target date:
|
|
|
|
bugs listed on the man page
|
|
|
|
hundreds of FIXME notes in the sources from WHN
|
|
|
|
various other unfinished business from CMU CL and before, marked with
|
|
"XX" or "XXX" or "###" or "***" or "???" or "pfw" or "@@@@" or "zzzzz"
|
|
or probably also other codes that I haven't noticed or have forgotten.
|
|
|
|
(Things marked as KLUDGE are in general things which are ugly or
|
|
confusing, but that, for whatever reason, may stay that way
|
|
indefinitely.)
|
|
=======================================================================
|
|
"There's nothing an agnostic can't do as long as he doesn't know
|
|
whether he believes in anything or not."
|
|
-- Monty Python.
|
|
|
|
"God grant me serenity to accept the code I cannot change, courage to
|
|
change the code I can, and wisdom to know the difference."
|
|
-- Erik Naggum
|
|
|
|
"Accumulation of half-understood design decisions eventually chokes a
|
|
program as a water weed chokes a canal. By refactoring you can ensure
|
|
that your full understanding of how the program should be designed is
|
|
always reflected in the program. As a water weed quickly spreads its
|
|
tendrils, partially understood design decisions quickly spread their
|
|
effects throughout your program. No one or two or even ten individual
|
|
actions will be enough to eradicate the problem."
|
|
-- Martin Fowler, in _Refactoring: Improving the Design of Existing
|
|
Code_, p. 360
|
|
|
|
"I wish I didn't know now what I didn't know then."
|
|
-- Bob Seger
|