Re: Light userdata

[RLake@...]

Hi, Dylan.

I didn't actually mean to send the last message to the whole list. Oh, 
well.

> I don't need integer math on vectors (they are all floats).

No, I understand that... but other people do :)

> The only thing I worry about is the overhead of turning what is 
basically an
> integral type to most CPU's into a full fledged table with a metatable 
to
> boot, that's quite a lot of interpreter overhead to simply access, say, 
the
> "x" element. (and a huge amount to add two vectors together using solely 
lua
> code)

Well, yeah. (I think you meant "atomic type" -- the word integral confused
me at first.)

That is an issue, which is why I thought of changing the *base*
numeric type for Lua into a vector. I know that sounds wierd, but if you
think about it long enough it starts to make some warped sense. It is not
actually that different from changing the base numeric type for Lua to
complex, which I did manage to do (but it was an outrageous hack -- I was
just trying to get my head around the VM).

Of course, it leaves open the question of how you extract pieces of a
vector; it probably needs adding an operator, although using [] is
very tempting.

> The latest compilers (vis. c, Intel etc) for the pentium use a 16-byte
> aligned stack so there are no problems passing 16-byte aligned data 
around
> (they don't pass SSE registers between functions yet mind you).

Yeah, I know. But there is no internal padding between items on the stack;
that is forbidden by the API. You can request compilers to pad doubles on
the stack, but that breaks binary library conformance and all sorts of
wierd things happen.

The problem arises when you have a function call whose arguments do not
have the same alignment; say something like:

  int foo(struct A *a, double b, int c)

The Pentium ABI says that a, b, and c are in consecutive 32-bit aligned
stack positions. It cannot be the case that b is correctly aligned in
this example. This is not a problem if all the arguments are doubles,
or even (on the Pentium) if all the trailing arguments are doubles
(since they are, I believe, pushed in reverse order).

Of course, now that I think about it, the Pentium ABI also says that
arguments bigger than eight bytes are passed by pointer, so I guess
it is actually not an issue at all for 128-bit arguments...

> Its not only the pentium though, almost all game consoles now have 128 
bit
> aligned vector data that can be copied about and operated on as freely 
(and
> as cheaply) as regular 32 bit integers and floats.

Yes, and also many embedded signal processors.

> How about an integral *table*? :-)

I'm not sure what you mean by this, actually... but I do have an idea...
Let me think about it some more...

R.