Go compiler moving from C to Go

Manu turkeyman at gmail.com
Mon Dec 23 16:30:50 PST 2013


On 24 December 2013 09:37, Iain Buclaw <ibuclaw at gdcproject.org> wrote:

> On 23 December 2013 23:02, Manu <turkeyman at gmail.com> wrote:
> > On 23 December 2013 22:06, bearophile <bearophileHUGS at lycos.com> wrote:
> >>
> >> Iain Buclaw:
> >>
> >>
> >> Did you really think that __simd went through a design phase? :-)
> >>
> >> I understand. So there is still a problem bigger than __simd.
> >
> >
> > To be fair, I don't think this is as significant as it sounds. I agree,
> > __simd had no real design, it was just a convenient implementation for
> DMD,
> > but isn't that always the case for compiler intrinsics? In most cases,
> LLVM
> > tries to mirror GCC intrinsics, but there are many significant
> distinctions
> > between LLVM and GCC's intrinsics, making versions in the code for each
> > compiler there too.
> > In my experience, there is always versioning issues when making use of
> > compiler intrinsics, what's important is that the language is able to
> wrap
> > them up cleanly and effectively. D currently satisfies this requirement
> to
> > some extent, but in my experience with std.simd, to get to the 100%
> mark, I
> > really need __forceinline. I can't really finish std.simd to a
> satisfactory
> > level without it.
>
> We have an @attribute("forceinline") for that... :o)
>

DMD doesn't, which is where it's needed the most >_<
Ideally, this needs to be standardised, so compiler-specific intrinsics can
be properly wrapped up.


And sorry, but some compiler intrinsics for DMD really do just shoot
> themselves in the foot.
>

Perhaps, but I'm able to make do with __simd in this case... at least, if I
could wrap it effectively.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20131224/8971ee29/attachment.html>


More information about the Digitalmars-d mailing list