[Arm-netbook] [review] SoC proposal

[lkcl luke]

On Thu, Feb 9, 2012 at 7:24 PM, Gordan Bobic <gordan at bobich.net> wrote:

>>   2) tensilica have a [proprietary] language "translator" (look it up
>> on wikipedia) which translates c and c++ into VLIW-aware c and
>> VLIW-aware c++ which the *STANDARD* gcc toolchain (that tensilica have
>> *ALREADY* completed) understands perfectly.
>
> Sounds suspiciously like the X-Burst way, and that's not really a sane
> proposition.

 tell me about it.  i've worked with aspex semiconductors "compiler"
technology: it was totally unable to cope with c++ especially
templates.  it basically took anything that had a block "asp { .... }"
 around it and literally turned it into c-code that plugged the
assembly-code directly into the memory-mapped registers!

 so, something like this:

 int do_stuff(int x)
 {
    asp {
    ASP_ADD(x, 5);
}

got turned into this:

int do_stuff(int x)
{
    *(0x1001000) = (0xE5A2A510);
    *(0x1001004) = x;
    *(0x1001008) = 5;
}

so... yeah, i'm thooorroughly familiar with how much of a failure
_that_ methodology can be :)  i did talk to the gcc developers to see
if they would be happy to do or accept a patch which allowed external
applications to process inline code-blocks, which was actually an idea
that had seriously been discussed before on the gcc lists... but then
the funding ran out and everyone but the core team who had been around
since the beginning of the company got fired.  oops!

anyway.  yes.  another thing on the "to discuss" list with the field
applications engineer.

l.