Problem with inline assembly and SSE

[Synfire]

1) malloc will return a pointer suitable aligned for standard C types. Since SSE??? types are non-standard, at least for the now "you are on your own".

Thanks for the clearification. For the most part I think we got any/all malloc-ing issues covered with everything done in this thread.

2) I have dropped support for the inline assembler in the 64-bit version, so maybe a good idea to prepare for the future and move to POASM anyway...

Truth is, that's really the way it should be. I've never really been a fan of inline assembly. It makes your C code less portable and you are working with a dumbed down version of assembler. All around it's best to just write your assembly routines seperate then call them from your C source code. So I fully agree with your descision there.

3) IIRC, __declspec(align(16)) should work for structures that are *initialized* ...

this will work:

Code: [Select]

__m128 a={0};
this will not work:

Code: [Select]

__m128 a;
since the latter case will end up in the comdat section, where an alignment can't be specified through COFF (AFAIK).

Awesome, Since there is a decent solution - I'd like to repost a feature request from earlier in this thread (in case you overlooked it)...

I would like to make a feature request for __declspec(align()) to work on variables. Like for example:

Code: [Select]

__declspec(align(16)) float myFloat[4]={0,0,0,0};

I think this would be an extremely useful feature. If it's too much trouble don't worry about it, but it would definately be nice to have for optimizing C routines by allowing manual insurance of stack alignment.

As I've said I'm mostly an assembly programmer (primarily NASM, GoASM, and POASM), I only use C for doing minor things (mostly psuedo code to test if an idea is going to work before I start actually writing the program) so it could be put on the very bottom of your todo list unless others want it also.

Regards,
Bryant Keller

[Greg]

timovjl,

That old example needs static keyword with initialization.

Thanks for the tip. It doesn't work without static.
 

[Pelle]

Perhaps I can do something about __declspec(align()) for variables later. It suspect it will take much more than "5 minutes", so not top priority at the moment...

[Synfire]

Oh yea, totally understand mate, no hurry. Just thought I would throw it out there while it was on topic.

[severach]

I've never really been a fan of inline assembly. It makes your C code less portable and you are working with a dumbed down version of assembler.

I disagree with both. Inline assembly encourages the use of assembly because it is more portable and smarter than a real assembler.

Inline assembly is more portable because you use #ifdef __POCC__ to select assembly or C code depending on the compiler and platform. Inline assembly is smarter because you get to use some C like constructs rather than writing pure TASM or MASM. Anything that makes assembly look more like C makes it better. Anything that makes assembly look less like C makes me less likely to use it, which may be your intent.

Perhaps you don't like the limited functionality of Pelles inline assembly when compared with Borland or GCC implementations.

[JohnF]

I agree with Severach in that I'm for inlined asm. Although I mainly code in C, to have the possibility of using inlined asm when needed is a great plus.

John
 

[Synfire]

Inline assembly is more portable because you use #ifdef __POCC__ to select assembly or C code depending on the compiler and platform.

Most modern assemblers support a similiar directive for changing based on symbols (so portability between various platforms can be achieved in much the same way). As for switching between C and Assembly, that's what I don't like. I personally prefer to keep such code seperated into different files. By doing that, you get to choose your prefered assembler and syntax. You can also use the various extentions, libraries, toolkits, etc. that have been developed for that assembler. For example, you mentioned MASM, an assembly programmer could make use of OA32 which comes with many modules for graphics, UI development, COM/OOP, etc. which could simplify a lot of work. Or for example Paul's GeneSys Library which has many procedures to simplify development on Win32 platforms built into linkable libraries for your development and include files for use with MASM. Notably I personally don't use any of these being a NASM/PoASM/GoASM user.. but they are examples as to what I was talking about as far as why a person should work their assembly code seperately from their C code.

Inline assembly is smarter because you get to use some C like constructs rather than writing pure TASM or MASM. Anything that makes assembly look more like C makes it better. Anything that makes assembly look less like C makes me less likely to use it, which may be your intent.

True, my source isn't normally in a very "high level format" compared to many people. But I just see it as, if you are going to use C, use C, if you are going to use assembly, use assembly. If you want something in between, go look at some of the psuedo-assemblers like HLA or EASM.

Perhaps you don't like the limited functionality of Pelles inline assembly when compared with Borland or GCC implementations.

Never used anything from Borland other than TASM and never really liked it all that much. As for GCC, I don't particularly care for AT&T syntax assembly, I'll use it if I have to but that's about as far as it goes. Even when I get stuck coding with GAS I normally switch over using .intel_syntax first chance I get.

I agree with Severach in that I'm for inlined asm. Although I mainly code in C, to have the possibility of using inlined asm when needed is a great plus.

John

Emphasis on "a great plus". I can agree with that. There are a few circumstances where inline assembly can be "a great plus" like when the compiler doesn't want to generate the opcodes you are expecting and you can't seem to figure out a way to make it do it. Just use __asm() and insert the opcodes yourself. Or when you want to use the compiler's optimizer, but you want to make sure that a certain set of opcodes are produced at a certain point (I've had that happen two or three times). And another good one is __asm(int 3) to generate a breakpoint; I actually have a macro which displays a message with fprintf to stderr and is followed by an int3 hardware breakpoint. The macro only inserts that code whereever the DPRINTF(...); lines are if __DEBUG__ is defined. So yea, there are some circumstances where it can be "a great plus" but for overall code design I don't suggest people become reliant on it and I personally consider it to be a bad programming practice.

Regards,
Bryant Keller