Exupery for sub-pixel font filtering.

[bryce at kampjes.demon.co.uk]

Andrew Tween writes:
 > Is the primitive compilation something that I, or others, could help with? What
 > is involved in adding a primitive to Exupery?
 > 

Primitives vary. Simple primitives may only be two lines with two
different tests covering them. Exupery is tested both by compiling
methods then testing they work correctly and also by unit tests that
test the individual components.

   primitiveLoadInstVar: aMedPrimitive 
       ^emitter 
	   fetchAddress: (MedLiteral literal: aMedPrimitive primitiveNumber - 264)
	   ofObject: (aMedPrimitive arguments first visitWith: self)

Is the simplest primitive in Exupery at the moment. It's the quick
return primitive to return an instance variable. This is a primitive
to save the cost of creating a context.

The primitives are in the category primitive in
IntermediateSimplifier. The end to end tests are in the category "Test
- Primitives" in ExuperyStoryTests. The unit tests are in "Tests -
Primitives" in IntermediateSimplifierTests.

#at: and #at:put: primitives will be much easier to write than
floating point primitives. #new involves calling C and also saving
state around a potential GC call. 

Decently optimised floating point primitives will require some
cleaning up of the front end to generalise the inlining of integer
code. Ideally, it should be possible to guess the type of an operation
then to forget the guess if type feedback shows it was wrong. This
would generalize the inlining done manually for arithmetic primitives
with the dynamic primitive inlining done for #at: etc.

 > Thanks for your comments. I had intended to re-write the method in C and add it
 > to the plugin, but the advantages of being able to easily play with it in
 > Smalltalk outweigh the speed-up of porting to C, at least while I am still
 > experimenting.

Writing a single primitive in C would be less work than optimizing
Exupery to handle everything needed for near C speeds.

Bryce