Commit 8ae30132 authored by David Schleef's avatar David Schleef

update release docs

parent f5697e3e
......@@ -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):
......
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
=====
......
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
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment