From: thinman@netcom.netcom.com (Lance Norskog)
Subject: Re: 386 renderer progress
Date: Wed, 8 Jan 92 18:58:47 PST



About step #17: Conversion To Assembler

This, in the form you contemplate, is a bad idea for 2 reasons:
	1) it renders your work non-portable to other more
	deserving hardware (PC's are really icky), and

	2) it is sub-optimal

Recently Byron Rakitzis re-wrote a subset of an image-processing language
(POPI, from the book "The Digital Darkroom") in incremental
compilation form.  He wrote code generators for MIPS and SPARC
processors, and wrote the basic language operators to
generate code through the generation routines.  The generators
allocate registers on the fly, and use the processor
very effectively.  The code is free, and the individual
generators are only five hundred lines of C.  It's in
comp.sources.misc, volume 26, issue 111.

Such a system would need a processor-independent front end that
implements basic blocks and translates float ops into
raw integer arithmetic.  I claim that such a front end can do a
better job on float->integer than you can coding it by hand
because it knows when it doesn't need to renormalize results.
This is especially true if you use rational arithmetic instead
of radix-point fixed arithmetic.  

More important, the overhead of repetitively walking data structures
in screen updates can be removed by compiling seperate code chunks 
for each polygon vertex.  These can be just procedure calls,
in-line copies of the clipping code, or whatever there's room for.

RAM is cheap now; there is no premium for 4meg simms over 1meg simms
($160 v.s. 4 * $40).  Hot-generated code with unrolled loops
is an excellent use for it.

This "conversion to assembler" would be much more portable AND efficient.

Lance Norskog