Boost logo

Boost :

Subject: Re: [boost] [context] Don't hard-code the assembler
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2014-04-08 05:27:49


On Tue, Apr 8, 2014 at 12:18 PM, Oliver Kowalke
<oliver.kowalke_at_[hidden]> wrote:
> 2014-04-08 9:31 GMT+02:00 <pmenso57_at_[hidden]>:
>
>>
>> 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.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk