[Ecls-list] Type propagation

[Alexander Gavrilov]

> On Sat, Jun 5, 2010 at 11:54 AM, Alexander Gavrilov <angavrilov at gmail.com>wrote:
> > I wonder how difficult might it be to add a few more primitive
> > unboxed types and builtins using them?

> 
> It would be easy, just changing cmpffi.lsp to add them as C representations
> of certain lisp types, and then adding inline forms for certain operations,
> such as addition, subtraction etc, in cmpnum.lsp, plus some functions in the
> core to convert to/from them.

It will obviously require introducing one or more opaque internal
lisp types with a boxed representation, and special functions to
work with them as well. If the compiler supports it, the function
definitions probably should be placed into a separate module
(e.g. a contrib), but the types have to be supported in the core.

> But I am not sure what those types are and how well would they integrate
> with their C counterparts. Are they efficient? What is their use?
> Furthermore, are they not supported by GCC already via long long or long
> double?

They represent 128-bit xmm registers, and are used with special
intrinsic functions that map to SSE instructions:

http://msdn.microsoft.com/en-us/library/708ya3be%28v=VS.71%29.aspx
http://msdn.microsoft.com/en-us/library/4atda1f2%28v=VS.71%29.aspx
etc etc

They are supported at least by Intel compilers, GCC and MSVC.

On x86-64 the instructions are available by definition; in 32-bit
mode special compiler options are required, e.g. -msse2 for GCC.

Actually, the CPU mostly doesn't distinguish the data types
stored in the registers (the operation is defined by the
instruction used), but the C interface uses separate names
for integer, single-float and double values.

Obviously, this all can be accessed via c-inline, but having
integrated support would probably be somewhat more convenient.

Alexander