[Arm-netbook] [review] SoC proposal

[Gordan Bobic]

On 02/09/2012 06:14 PM, lkcl luke wrote:
> On Thu, Feb 9, 2012 at 6:07 PM, Vladimir Pantelic<vladoman at gmail.com>  wrote:
>> Tony Garnock-Jones wrote:
>>> On 02/09/2012 11:56 AM, Gordan Bobic wrote:
>>>>   The downside is that you need a damn good compiler to leverage it - and
>>>>   GCC isn't it.
>>>
>>> This is where Nile/Gezira come in: you actually need more than a damn
>>> good compiler, you need a better language - and C isn't it.
>>
>> So, to sum it up, we have many nonstandard tensilica VLIW cores that we
>> will not program with gcc but with some other compiler and not using C
>> but some other language, but we will port existing Linux kernel and
>> userland to it quickly, right? :) :) :) let's go! :)
>
>   :)
>
>   no, completely and utterly wrong!
>
>   1) the linux kernel, toolchain etc. (and buildroot and a couple of
> other embedded environments) have already been done.

In a way that leverages the CPU's VLIW capabilities? If you're going to 
optimize one package it's usually glibc because _everything_ uses it.

>   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. Unless it is a proper gcc back-end, you'd have to change 
the build method of every package to pre-process before building. I 
don't really think that's workable.

>   3) if the option of adding the VLIW extensions is too complex for
> good-old free software land to comprehend, then we just leave them
> out, and find another way to get the required performance.

It's not too complex to comprehend, it's just hard to get right, and it 
takes extremely skilled people paid extremely good money to actually do 
it properly. MMX CPUs have been around since 1995 and SSE since 1999. 
Assuming GCC can vectorize worth a damn today (don't know for a fact 
that it does, I haven't tried it recently, 18 months ago it certainly 
couldn't), that would mean it took somewhere between 15 and 17 years for 
the OSS to catch up with the times, despite all the contributions from 
AMD, IBM, and other big names.

If that is the benchmark, a VLIW back end for GCC may just about be 
ready by 2030. Is that's the target release schedule for this new SoC?

>   that's not all - please do not go misunderstanding what i've written
> there [like "oh it's a proprietary VLIW compiler therefore it will
> stay that way therefore this project will fail"] - i haven't even got
> into negotiations yet with their applications engineer (he's back next
> week) in order to raise the possibility of them releasing the VLIW
> language-translator as a Free Software Project.

You're missing the point - a translator like what you describe isn't 
enough, even if it was open-sourced. No self respecting Linux distro 
would change all the packages to accomodate this one platform that 
doesn't do it properly.

As I said before - a pre-processor bodge is fine for makers of one-off 
Android slates and other dime-a-dozen appliances that are never going to 
be used by OSS developers, but it is completely unworkable for proper 
OSS porting.

Gordan