From 1d5d9f466d5cf2fb40506c5a2b9eb09fded1a40c Mon Sep 17 00:00:00 2001 From: Søren Sandmann Pedersen Date: Sun, 1 Sep 2013 19:45:06 -0400 Subject: iterjit --- iterjit.c | 52 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 52 insertions(+) create mode 100644 iterjit.c 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. +*/ -- cgit v1.2.3