On 2010-03-08 06:37:55 -0500, Walter Bright <[email protected]> said:
grauzone wrote:
I don't understand, what does alignment have to do with such a high
level construct?
You can use a tuple to populate a struct with fields, and it's
interchangeable with manually populating the fields. You can also use a
tuple to pass args to a function, and it's interchangeable with
manually listing the args.
But if you populate a struct with a tuple, then pass the struct as an
arg, it is *not* interchangeable with manually listing the args, as the
alignment is different.
I think a better way to explain it is that a struct having an align(x)
instruction will have different alignment than a struct with no
explicit alignment, so you can't easily pass the tuple without creating
a different copy with a standard alignment. For instance:
struct CustomAligned { align(2): byte a; short b; }
struct DefaultAligned { byte a; short b; }
tuple(byte, short) foo();
CustomAligned a;
a.tupleof = foo(); // how does this work under the hood?
DefaultAligned b;
b.tupleof = foo(); // how does this work under the hood?
I think a nice ABI for this would be to pass small tuples like the one
above in registers. Bigger tuples would be returned the same way as a
struct having default alignment. If you're copying the tuple to a
struct with non-default alignment, like in the example above, then it's
the caller's responsibility to allocate temporary space on the stack
and move the values as needed afterward. This would make the
non-default alignment case slower, but using non-default alignment is
already bound to be slower for many things.
Another option is to pass a hidden pointer to each member as BCS
suggested. Though I suspect this would be slower when assigning to
default-aligned structs.
It's not an impossible problem, but indeed it's not as simple as
returning a struct. Is there some other issues I missed?
--
Michel Fortin
[email protected]
http://michelf.com/
