-*- mode: org; mode: auto-fill -*-
Who woulda thunk people want to port this?
No #+sbcl #-sbcl in source files that exist for other reasons than portability.Nikodemus will not maintain portability: SBCL port will be the canonical one.Uglified code is allowed in shared files if it makes things faster for SBCL.Uglified code is not allowed in shared if it makes code faster for implementation X. (Put it in an implementation specific file instead.) Add file to build with feature dep.define SB-CGA::DEFKNOWN as an empty wrapper around SB-C:DEFKNOWN, etc.These files will define appropriate versions of SB-CGA::DEFKNOWN, etc.
Probably add vm-<impl>.lisp which should contain the DEFINE-VOP equivalents, so that the load-order would be something like fndb.lisp (defknowns for the whole system), vm-<impl>.lisp (define-vop equivalents for ports that have them), vm-common.lisp (stuff in vm2.lisp, mostly).
Looking at ccl.lisp, aside from the NaN issues a generic port should not be too hard. To work around the unportability of NaN a generic port could maybe use NIL for NaN and most-positive/negative-single-float for infinities.
Iff there are at least two ports with maintainers that use them and will probably continue to do so.
WIP Overview What SB-CGA is and isn’t. What sort of things may change if you use the repo directly. Design choises relating to single/double floats.WIP VectorsdocstringsUsing dynamic-extentoptimizations doneWIP MatricesdocstringsWIP Root solversdocstringsnew rootsMiscellany NORMALIZED-VECNORMALIZED-CROSS-PRODUCTNORMALIZED-TRANSFORM-POINT The reason these seem worthwhile is that they avoid memory traffic – but it is probably not a good idea to expose them as part of the interface!ADJUST-VECImplement VEC-MIN/MAX using MINPS/MAXPS.Tests for these TestsVECPPOINTPVECTOR3PVEC= TestsALLOC-VECVECCOPY-VEC, %COPY-VECPOINTVECTOR3POINT->VECTOR3VECTOR3->POINT VEC+, %VEC+VEC-, %VEC-VEC*, %VEC*VEC/, %VEC/DOT-PRODUCTHADAMARD-PRODUCT, %HADAMARD-PRODUCTVEC-LENGTHVEC-LERPNORMALIZE, %NORMALIZEVEC-MIN, VEC-MAXCROSS-PRODUCT