update release docs

diff --git a/README b/README
index a0c2c1a..4e53ce9 100644 (file)
--- a/README
+++ b/README
@@ -39,8 +39,8 @@ Features:
  - An application can add rules for converting existing or new opcodes
    to binary code for a specific target.
 
- - Current targets: SSE, MMX, ARM, Altivec, NEON, and TI C64x+.  (ARM
-   is very limited and c64x only produces source code.)
+ - Current targets: SSE, MMX, ARM, Altivec, NEON, and TI C64x+.
+   (The c64x target only produces source code.)
 
  - Programs can optionally be emulated, which is useful for testing, or
    if no rules are available to convert Orc opcodes to executable code.
@@ -72,11 +72,12 @@ Questions and Answers:
 
  - Q: How big is the Orc library?
 
-   A: For embedded users, patches can be applied that disable irrelevant
-   targets.  Compiled with only one target (SSE), the library size is
-   about 95 kB uncompressed, or 32 kB compressed.  The goal is to keep
-   the uncompressed size under about 100 kB.  A typical build with all
-   targets and the full ABI is around 300 kB.
+   A: For embedded users, the --enable-backend configure option can
+   be used to disable irrelvant targets.  Compiled with only one target
+   (SSE), the library size is about 150 kB uncompressed, or 48 kB
+   compressed.  The goal was to keep the uncompressed size under
+   about 100 kB (but that failed!).  A typical build with all targets
+   and the full ABI is around 350 kB.
 
 
 Caveats (Known Bugs):

diff --git a/RELEASE b/RELEASE
index 37c85a3..febd7cc 100644 (file)
--- a/RELEASE
+++ b/RELEASE
@@ -1,4 +1,46 @@
 
+0.4.6
+=====
+
+Changes:
+
+ - Various fixes to make Orc more portable
+ - Major performance improvements to NEON backend
+ - Minor performance improvements to SSE backend
+ - Major improvements to ARM backend, now passes regression
+   tests.
+
+The defaults for floating point operations have been changed
+somewhat: NANs are handled more like the IEEE 754 standard,
+and denormals in operations are treated as zeros.  The NAN
+changes causes certain SSE operations to be slightly slower,
+but produce less surprising results.  Treating denormals as
+zero has effects ranging from "slightly faster" to "now possible".
+
+New tool: orc-bugreport.  Mainly this is to provide a limited
+testing tool in the field, especially for embedded targets
+which would not have access to the testsuite that is not
+installed.
+
+The environment variable ORC_CODE can now be used to adjust
+some code generation.  See orc-bugreport --help for details.
+
+orcc has a new option to generate code that is compatible
+with older versions of Orc.  For example, if your software
+package only uses 0.4.5 features, you can use --compat 0.4.5
+to generate code that run on 0.4.5, otherwise it may generate
+code that requires 0.4.6.  Useful for generating source code
+for distribution.
+
+New NEON detection relies on Linux 2.6.29 or later.
+
+Plans for 0.4.7: (not that past predictions have been at all
+accurate) New opcodes for FIR filtering, scaling and compositing
+of images and video.  Instruction scheduler, helpful for non-OOO
+CPUs.  Minor SSE/NEON improvements.  Orcc generation of inline
+macros.
+
+
 0.4.5
 =====
 

diff --git a/TODO b/TODO
index 5a382d0..dbc522c 100644 (file)
--- a/TODO
+++ b/TODO
@@ -1,5 +1,26 @@
 
 
+sse: Handle cache information and small n
+
+neon: constant n
+
+aligned source checks
+
+new opcodes:
+  - sampling: video scaling, fir filtering, fir filtering with
+    downsampling, upsampling/downsampling
+  - composite opcodes
+
+float parameters
+
+compiler: inline orc calls
+
+compiler: initialization function
+
+instruction scheduler
+
+improve emulation
+
 
 
 0.5