On Tue, Apr 8, 2014 at 12:18 PM, Oliver Kowalke
2014-04-08 9:31 GMT+02:00
: That is exactly what the rest of Boost has to do with C++ compilers. Workarounds and alternate implementations abound. I am fully aware of the burden this places on the typical Boost developer. Personally, I would prefer "unsupported" over fallback to a different toolset (or assumption of said toolset).
it is not exactly as with C++ - the C++ syntax is standardized and you have to fix only the code on some small place for some C++ compilers. with assembler I've to rewrite the complete code - for instance how values are stored in a register varies from toolset to toolset, char defining a comment varies etc.
I wonder if it's possible to translate between masm and gas syntaxes on the fly. I know gas understands Intel notation for x86 instructions but I'm not sure if that extends to other aspects of the syntax. Also, as a side note, many opensource projects with asm code limit themselves with just one assembler (I'd say yasm is one of the most popular ones). This isn't really a problem as long as the required tool is available and free for all target platforms. I think it is ok if Boost.Context limits the set of supported assemblers, although I'm not sure that supporting only masm on Windows is a good idea. I'd prefer an open alternative, even if it is not the standard one shipped with VS. Otherwise Boost.Context becomes vendor-locked on that particular platform. yasm is really good in this respect - it is widely available, lightweight and opensource. Disclaimer: I'm not a user of Boost.Context.