Hi,

I need a 16 byte alignment on certain value types to accurately mirror value classes we pass into our interface. I've tried overloading the memory allocator but that does not seem to work, I still get unaligned addresses for value types created by AngelScript.
I noticed there is an 8 byte alignment flag, but that does not seem to do anything at all.

Could you point me to where I can modify this and turn the 8byte into a functional 16 byte alignment flag?

Thanks!

I turned it into a scoped reference type for now. Seems to work ok so far.

So far the only way to guarantee memory alignment is with scoped reference types.

I have plans to add support for per-type memory alignment with registered types, but it is not an easy thing to do, and is quite low on my priorities.

I've run into a problem with the scoped reference type.

I have the following registration call:
[source lang="cpp"]

r = _engine->RegisterObjectMethod("vector", "vector &opAdd(const vector &in) const",
asMETHODPR(Vector, operator+, (const Vector &) const, Vector), asCALL_THISCALL);

[/source]
and this binds to a class method of class Vector that is declared like this:
[source lang="cpp"]

Vector operator+( const Vector& _rhs ) const;

[/source]
There seems to be no way to declare the method in a working fashion. If I leave the reference out in the angelscript type, I cannot register the method. If I remove the reference on the c++ side, I hit a road block because it is 16 bytes aligned and value parameters do not work with alignment restrictions.

If I use both the way they are, I get a 0-pointer on the _rhs parameter.

Any ideas on how to work around this?

Thanks!

ps.: I dug up the old post so you knew the troubles I had with declaring vector a scoped reference and why I did it.

The problem appears to be amazingly similar to http://www.gamedev.net/topic/507813-operator-addsubmultiplydivide-with-scoped-types/

Unfortunately you can only register this method through a wrapper, as AngelScript requires that the scoped type is allocated on the heap where the application controls the alignment.

Here's an example wrapper:


Vector *wrapper_VectorAdd(const Vector &_lhs, const Vector &_rhs)
{
return new Vector(_lhs + _rhs);
}

// Registered as...
r = _engine->RegisterObjectMethod("vector", "vector @opAdd(const vector &in) const",
asFUNCTION(wrapper_VectorAdd), asCALL_CDECL_OBJFIRST);


Despite the scoped type not normally supporting handles, it should still be used in this case to let AngelScript know you're returning a new instance, rather than a reference to an existing instance. This will allow AngelScript to free the object after using the returned instance.


I have plans to implement support for memory aligned value types. However, this is unfortunately a very complex subject, where the alignment needs to be guaranteed everywhere, local variables on the stack, as members of a class, when returned from an application function, etc. And most importantly since this needs to be guaranteed in the platform independent bytecode too where the alignment requirements can be different on different platforms.

With modern SIMD architectures, we're looking mostly at 4 and 16 byte alignments. If AS would provide those two, my guesstimate is that almost everyone is happy.

If your class needs 8 bytes alignment, you are probably happy with 16 byte alignments, too.
If your class needs alignments over 16 bytes, you are most likely ok to allocate the memory in a different location and wrap the access. (e.g. 4k pages etc.)

If an align16 object flag is reasonably easy to implement, that would be fabulous. Right now, I had to switch to unaligned reads for my simd types which makes the bridge between native and scripted code somewhat cumbersome. No, I am not going to do performance relevant math operations in scripts but passing values in and out of registered functions that use an equivalent math class like we have in the native code makes it easier to read and maintain.

Doing 8 or 16 byte alignments, or both, is about the same complexity. The complexity doesn't come from size of the alignment, but rather from the restriction that there is an alignment that needs to be guaranteed, and that this alignment can be different on different platforms.

For now I would suggest continuing to use scoped reference types, and wrap only those functions/methods that take or return the Vector by value. This is in my opinion much less work than to use two completely different types to represent the memory aligned and non-memory aligned Vector type.

Hi,

I tried to implement your wrapper idea but it seems that the type registration does not allow @ modifiers when using scoped types.
[source lang="bash"]Object handle is not supported for this type
Failed in call to function 'RegisterObjectMethod' with 'vector' and 'vector @opAdd(const vector &in) const' (Code: -10)[/source]

Any ideas? The signature of the wrapper is like you mentioned in your post.

Thanks for the help!

Never mind, forgot to switch the type registration from value back to scoped. .. .