iterjit

1 files changed, 52 insertions, 0 deletions

diff --git a/iterjit.c b/iterjit.c
new file mode 100644
index 0000000..64e32ed
--- /dev/null
+++ b/iterjit.c
@@ -0,0 +1,52 @@
+/*
+  
+  Iterator based JIT compiler
+
+  There is a new structure that can be either source or
+  destination. It contains function pointers that know how to generate
+  pixels. The function pointers:
+
+  Source iterators:
+
+  - begin():		generates code that runs before the kernel
+  - begin_line():	generates code that runs before each scanline
+  - get_one_pixel():	   generates code that reads one pixel
+  - get_two_pixels():	   --- two pixels
+  - get_four_pixels():	   --- four pixels
+  - get_eight_pixels():	   --- eight pixels
+  - get_sixteen_pixels():  ---
+  - end_line();
+  - end();
+
+  An iterator is associated with a format:
+
+  format_4_a8r8g8b8
+  format_16_a8
+  format_8_a8r8g8b8
+  and possibly others
+
+  The iterator is supposed to return pixels in that format. It will
+  never be asked to fetch more pixels than the format supports. Ie.,
+  get_sixteen_pixels() will never be called if the format is
+  format_4_a8r8g8b8().
+
+  All the get_n_pixels() return a register where they left the pixel.
+
+  There are also combiners. These are also associated with a format
+  and know how to combine pixels in that format with each other.
+
+  Destination iterators are responsible for driving a lot of the access?
+
+  They have a method: process_scanline (src_iter, mask_iter, combiner)
+  which is responsible for:
+
+  - generating the inner loop,
+  - calling src iter,
+  - callling mask iter,
+  - calling combiner
+  - writing back
+
+  They are specific to a format, and an intermediate format.
+
+  There may also be setup()/setup_line() methods required.
+*/