- Dec 05, 1997
-
-
dtc authored
the raw address before calling, saving two bytes. This was probably done in case the static function is a closure, but to work this would need to load EAX with the fdefn pointer and jump to the fdefn raw slot - none of the static functions are closures anyway.
-
dtc authored
to another.
-
dtc authored
the control stack in sub-access-debug-var-slot.
-
- Dec 04, 1997
-
-
dtc authored
With the :propagate-fun-type feature, modify defknowns for exp, sin, cos, atan, tan, sinh, cosh, asinh not to call result-type-float-contagion because each has its own optimizer now.
-
dtc authored
Fixed small bug in elfun-derive-type-1: When a complex number is passed in, we don't want to just copy that as the result. We want the same type of complex number but with no bounds included. New function float-or-complex-type to compute the union type (or float (complex float)) with the appropriate type of float and bounds, if needed. At the end compiler/float-tran.lisp, the derive-type optimizers for sin, cos, and tan, are never enabled, because of a misspelling of propagate-fun-type (was progagate-fun-type). Plus a few fixes for these. Added expt derive-type optimizer, should handle all cases. Added derive-type optimizers for conjugate and cis.
-
dtc authored
-
- Dec 03, 1997
-
-
dtc authored
(setf get-context-values). The return addresses are now stored in sap-reg and sap-stack SCs, so there is now need to detect alternate references to these locations and map them to the sap-ref and sap-stack locations.
-
dtc authored
storing these in the sap-reg and sap-stack SCs. This is a more natural representation now that the debugger handles the return addresses as SAPs.
-
dtc authored
call_into_lisp is handled by x86-assesm.S.
-
dtc authored
were being allocated, the frame pointer was pushed then three more slots allocated. At most three slots are needed, so allocate just three. Perhaps only two slot are needed now, for the ofcp and return pc, the code slot is not used.
-
dtc authored
sequence.
-
dtc authored
-
dtc authored
-
dtc authored
not (complex (float -1.0 1.0))). From Raymond Toy.
-
dtc authored
Cleanup the verbose messages, making them all dependent on the verbose level, and disable them all by default.
-
- Dec 02, 1997
-
-
dtc authored
-
- Dec 01, 1997
- Nov 30, 1997
-
-
dtc authored
register but had not declared this register as a temporary.
-
dtc authored
suggested by Raymond Toy.
-
pw authored
-
dtc authored
Slight cleanup of these header files.
-
dtc authored
-
dtc authored
are zero filled and not write protected which should be the case. Make more of the consistency checks conditional and disable them all.
-
- Nov 29, 1997
- Nov 28, 1997
- Nov 27, 1997
-
-
dtc authored
o Fixed bug in real/imag part optimizers which didn't handle union types. o Added derive-type optimizer for complex. o Added deftransforms for complex operations: o complex-complex ops: + - * / o complex-float ops: + - * / o float-complex ops: + - *
-
dtc authored
-
dtc authored
x86 port under CGC and GENCGC.
-
dtc authored
-
- Nov 25, 1997
-
-
dtc authored
early stages so will have to be hand edited.
-
dtc authored
code into the dynamic heap.
-
dtc authored
-
dtc authored
-
dtc authored
improvement in reliability necessary for breakpoint and single stepping to have a chance, and has been tested in the experimental code and works on FreeBSD and Linux. The code object for a given return address in now located with the help of the GC support function component_ptr_from_pc which can reliably locate the code objects. This uses a forward search of the heap so is rather slow - some caching will be needed for better performance. The stack parsing has been re-written using a backtracking search to improve the chance of finding a valid frame path given that the control changes between C and Lisp conventions. The x86-lra hack is no longer necessary (was unreliable anyway) allowing x86 code to be more compact. The return address is now handled as a SAP which is acceptable because the code doesn't move with CGC, and GENCGC ensures that code objects in the dynamic heap with return addresses on the stack are not moved. However there are known problems under GENCGC when return addresses are move off the stack during some breakpoint operations in which case the code object may move.
-