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