<br><br><div class="gmail_quote">2012/2/9 lkcl luke <span dir="ltr"><<a href="mailto:luke.leighton@gmail.com">luke.leighton@gmail.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On Thu, Feb 9, 2012 at 7:24 PM, Gordan Bobic <<a href="mailto:gordan@bobich.net">gordan@bobich.net</a>> wrote:<br>
<br>
>> 2) tensilica have a [proprietary] language "translator" (look it up<br>
>> on wikipedia) which translates c and c++ into VLIW-aware c and<br>
>> VLIW-aware c++ which the *STANDARD* gcc toolchain (that tensilica have<br>
>> *ALREADY* completed) understands perfectly.<br>
><br>
> Sounds suspiciously like the X-Burst way, and that's not really a sane<br>
> proposition.<br>
<br>
</div> tell me about it. i've worked with aspex semiconductors "compiler"<br>
technology: it was totally unable to cope with c++ especially<br>
templates. it basically took anything that had a block "asp { .... }"<br>
around it and literally turned it into c-code that plugged the<br>
assembly-code directly into the memory-mapped registers!<br>
<br>
so, something like this:<br>
<br>
int do_stuff(int x)<br>
{<br>
asp {<br>
ASP_ADD(x, 5);<br>
}<br>
<br>
got turned into this:<br>
<br>
int do_stuff(int x)<br>
{<br>
*(0x1001000) = (0xE5A2A510);<br>
*(0x1001004) = x;<br>
*(0x1001008) = 5;<br>
}<br>
<br>
so... yeah, i'm thooorroughly familiar with how much of a failure<br>
_that_ methodology can be :) i did talk to the gcc developers to see<br>
if they would be happy to do or accept a patch which allowed external<br>
applications to process inline code-blocks, which was actually an idea<br>
that had seriously been discussed before on the gcc lists... but then<br>
the funding ran out and everyone but the core team who had been around<br>
since the beginning of the company got fired. oops!<br>
<br>
anyway. yes. another thing on the "to discuss" list with the field<br>
applications engineer.<br>
<span class="HOEnZb"><font color="#888888"><br>
l.<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
_______________________________________________<br>
arm-netbook mailing list <a href="mailto:arm-netbook@lists.phcomp.co.uk">arm-netbook@lists.phcomp.co.uk</a><br>
<a href="http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook" target="_blank">http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook</a><br>
Send large attachments to <a href="mailto:arm-netbook@files.phcomp.co.uk">arm-netbook@files.phcomp.co.uk</a></div></div></blockquote></div><br><div>It seems that some work is already done in LLVM compiler infrastructure to support VLIW. More to come in LLVM version 3.1. Maybe you should contact them for more information about their goals and progress.</div>
<div><br></div><div>Xtensa is also mentioned in the LLVM source code. So I guess that at least there is support for the Xtensa RISC cores.</div><div><br></div><div>Info:</div><div><a href="http://stackoverflow.com/questions/4166176/llvm-compiler-infrastructure-for-vliw-architectures">http://stackoverflow.com/questions/4166176/llvm-compiler-infrastructure-for-vliw-architectures</a></div>
<div><a href="http://llvm.org/docs/ReleaseNotes.html#whatsnew">http://llvm.org/docs/ReleaseNotes.html#whatsnew</a></div><div><a href="http://llvm.org/Users.html">http://llvm.org/Users.html</a></div><div><br></div><div><br>
</div><div>Regards,</div><div><br></div><div>Iliya</div><div><br></div>