• FEATURED

View more

View more

View more

### Image of the Day Submit

IOTD | Top Screenshots

### The latest, straight to your Inbox.

Subscribe to GameDev.net Direct to receive the latest updates and exclusive content.

# 16 Byte Alignment on Value Types

Old topic!

Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

10 replies to this topic

### #1BClarenbach  Members

Posted 10 October 2012 - 03:57 AM

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!
Working with STL makes a lot more sense if you think about the "std::" as referring to Sexually Transmitted Diseases.

### #2BClarenbach  Members

Posted 10 October 2012 - 05:54 AM

I turned it into a scoped reference type for now. Seems to work ok so far.
Working with STL makes a lot more sense if you think about the "std::" as referring to Sexually Transmitted Diseases.

### #3Andreas Jonsson  Moderators

Posted 10 October 2012 - 06:54 PM

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.
AngelCode.com - game development and more - Reference DB - game developer references
AngelScript - free scripting library - BMFont - free bitmap font generator - Tower - free puzzle game

### #4BClarenbach  Members

Posted 05 December 2012 - 08:35 AM

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.

Edited by BClarenbach, 05 December 2012 - 08:41 AM.

Working with STL makes a lot more sense if you think about the "std::" as referring to Sexually Transmitted Diseases.

### #5BClarenbach  Members

Posted 05 December 2012 - 09:06 AM

The problem appears to be amazingly similar to http://www.gamedev.net/topic/507813-operator-addsubmultiplydivide-with-scoped-types/
Working with STL makes a lot more sense if you think about the "std::" as referring to Sexually Transmitted Diseases.

### #6Andreas Jonsson  Moderators

Posted 05 December 2012 - 10:49 AM

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",


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.

Edited by Andreas Jonsson, 05 December 2012 - 10:55 AM.

AngelCode.com - game development and more - Reference DB - game developer references
AngelScript - free scripting library - BMFont - free bitmap font generator - Tower - free puzzle game

### #7BClarenbach  Members

Posted 05 December 2012 - 10:56 AM

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.
Working with STL makes a lot more sense if you think about the "std::" as referring to Sexually Transmitted Diseases.

### #8Andreas Jonsson  Moderators

Posted 05 December 2012 - 11:19 AM

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.
AngelCode.com - game development and more - Reference DB - game developer references
AngelScript - free scripting library - BMFont - free bitmap font generator - Tower - free puzzle game

### #9BClarenbach  Members

Posted 06 December 2012 - 09:44 AM

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 typeFailed in call to function 'RegisterObjectMethod' with 'vector' and 'vector @opAdd(const vector &amp;in) const' (Code: -10)[/source]

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

Thanks for the help!

Edited by BClarenbach, 06 December 2012 - 09:48 AM.

Working with STL makes a lot more sense if you think about the "std::" as referring to Sexually Transmitted Diseases.

### #10BClarenbach  Members

Posted 06 December 2012 - 09:54 AM

Never mind, forgot to switch the type registration from value back to scoped. .. .
Working with STL makes a lot more sense if you think about the "std::" as referring to Sexually Transmitted Diseases.

### #11Andreas Jonsson  Moderators

Posted 06 December 2012 - 11:26 AM

AngelCode.com - game development and more - Reference DB - game developer references
AngelScript - free scripting library - BMFont - free bitmap font generator - Tower - free puzzle game

Old topic!

Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.