Instead of code procedures...

[Brian Hawley <bhawley@luc.edu>]

Hi all!

The recent discussion about code procedures got me thinking, what do we use
these for anyways? 

In most cases code procedures are used to implement behavior that is quite
system-specific, both in the sense of being non-portable and of being often 
used on that particular system for low-level stuff. An example of this would 
be (on Dos) the FPU functions not otherwise in the language, the system
interrupts and other additional shortcut instructions. Code procedures are 
one way to implement these, but they don't interact well with GSA code; the 
compiler essentially has to MayAlias the whole machine. Another way would be 
to make the compiler recognize certain patterns in the code and do system-
specific optimizations to it, a compiler-design task that would be too 
difficult to bother with.

Perhaps I missed it, but I never heard the SYSTEM module mentioned. I know 
that everyone seems to implement SYSTEM in the Ceres style, but this kind of 
problem is exactly what it was intended for in the first place: extending 
the language for non-portable work. I know that I could speed up the *Math 
modules a great deal on the Intel chips if SYSTEM exported a few functions 
that implemented the extra functions on the Intel FPU, like sincos and ln. 
I'm sure that other such opportunities exist on other architectures.

Could we possibly provide a way for a backend to extend the SYSTEM module 
with its own clever hacks? We could request that the Ceres stuff be done as 
a minimum if we want, but anything beyond that could be could be up to the 
backend designer. It should be easy enough to figure out which hacks would be 
most useful to most people on a given system, if only through working on the
non-portable sections of the standard library. Any special optimizations that
the compiler could exploit would be known then. If something more unusual is
needed, there would still be code procedures to fall back on.

If we can do something like this already, let's use it! 

Cheers!
Brian Hawley
bhawley@luc.edu