Re: [B2-devel] Inline Assembly Query

[Frank T. <fra...@gm...>]

Standard MacPorts gcc failed last time I tried, although I cannot remember
why.

On Mon, Jun 18, 2012 at 7:34 PM, Charles Srstka <
bas...@ch...> wrote:

> On Jun 18, 2012, at 7:27 PM, Frank Trampe wrote:
>
> __op_PARAM1 is defined as a static or external and possibly signed integer
> (depending upon platform) in dyngen-exec.h. The operation is apparently
> (judging from the 32-bit branch) designed to stuff the value of __op_PARAM1
> (which is normally 32 bits but could be shorter or longer) into A0 (which
> is 64-bit on x86-64). I am not familiar with the __op_ token in asm and
> cannot find any information on it. Does anybody know what is happening
> here? Would it be unreasonable to allow the simple assignment if a long on
> the platform in question is the same size as the target register?
>
>
> I think the problem might actually be the global register variables A0,
> A1, A2, T0, T1, T2. LLVM doesn’t like those. This is what clang complains
> about if you try to compile with it instead of LLVM-GCC, at least.
>
> The easiest, if not the most satisfying, way to get BII/SS compiling on
> newer systems might be to get them to work with the various gcc ports
> available via MacPorts. I’ve been playing with that today, and getting
> sanity check errors in the configure script. Trying to figure out what’s
> going on there right now.
>
> Charles
>
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> basilisk-devel mailing list
> bas...@li...
> https://lists.sourceforge.net/lists/listinfo/basilisk-devel
>
>