Prev: [ANN] LBW 0.1: Linux Binaries on Windows
Next: IPC based on name pipe FIFO and transaction log file
From: David Given on 3 Apr 2010 13:38
On 03/04/10 18:02, Måns Rullgård wrote:
[...]
> Fortunately, most
> embedded systems are ARM or MIPS, both well supported by gcc and
> various commercial compilers. There is very rarely any need to stick
> with the outdated junk hardware vendors give you.

gcc doesn't produce brilliant ARM code --- if you compare it with
something like RVCT (ARM's own proprietary C/C++ compiler) you can see
just how much room for improvement there is. I've heard from a company
that produced a software 3D engine for ARM devices that simply
recompiling their code with RVCT produced a 30% improvement in frame rate.

OTOH gcc is free and RVCT is enormously expensive...

OTGH, we did have one customer whose development system was based on
Montavista Linux. The SDK for this costs around $25k per seat, which
they were expecting us to pay for. After finally persuading them to give
us a short-term evaluation license we discovered that what you got for
your money was actually gcc and Eclipse. *shrug*

The least bad commercial compiler I ever dealt with was for a deeply
obscure and short-lived processor called the ShBoom, a.k.a. the PSC1000.
This was a weird processor that was designed to run Forth and Java
bytecode more or less directly; it was stack-based, but also had about
32 registers, some of which were shared with a tiny CPU core that
handled memory refresh. Other features included the bottom half of an
FPU but not the top half, and an instruction encoding scheme that varied
depending on the alignment of the instruction. OTOH the compiler was
very fast and produced really good (and astonishingly tight!) code. I
have no idea who made it.

[...]
> The one bug I spent the longest time (almost a week) to find was
> caused by a Green Hills compiler. Since that time, I have a bit of a
> distrust for them. Other compiler bugs I've found were mostly in very
> obscure construct; this one was in a simple return statement.

I don't know Green Hills, but I did deal with a *different* customer
whose code was all compiled with ADS 1.2 --- a very old version of RVCT.
I spent a happy month or so finding bugs in that, mostly due to faulty
64-bit arithmetic. Fun, isn't it?

--
┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ───── http://www.cowlark.com ─────
│
│ "In the beginning was the word.
│ And the word was: Content-type: text/plain" --- Unknown sage
From: Måns Rullgård on 3 Apr 2010 19:12
David Given <dg(a)cowlark.com> writes:

> On 03/04/10 18:02, M�ns Rullg�rd wrote:
> [...]
>> Fortunately, most
>> embedded systems are ARM or MIPS, both well supported by gcc and
>> various commercial compilers. There is very rarely any need to stick
>> with the outdated junk hardware vendors give you.
>
> gcc doesn't produce brilliant ARM code ---

I know that, but it's miles better than the code it produces for more
obscure targets.

> if you compare it with something like RVCT (ARM's own proprietary
> C/C++ compiler) you can see just how much room for improvement there
> is.

About 10% on average in my experience. In one extreme case RCVT
produced twice as fast code as gcc.

> I've heard from a company that produced a software 3D engine for
> ARM devices that simply recompiling their code with RVCT produced a
> 30% improvement in frame rate.

That big a difference is unusual, but I can believe it. I do suspect,
however, that the C code wasn't optimal. Well-tuned C code doesn't
generally exhibit that much variation.

> OTOH gcc is free and RVCT is enormously expensive...

My point is that there are an abundance of ARM compilers, all
ABI-compatible, so you can choose whichever one _you_ prefer.

> OTGH, we did have one customer whose development system was based on
> Montavista Linux. The SDK for this costs around $25k per seat, which
> they were expecting us to pay for. After finally persuading them to give
> us a short-term evaluation license we discovered that what you got for
> your money was actually gcc and Eclipse. *shrug*

Montavista is well-known for such scams. They even put a DRM-like
thing in their gcc. They still provided source code, so you could
easily remove it. I guess they were just doing their part collecting
the gullibility tax.

> The least bad commercial compiler I ever dealt with was for a deeply
> obscure and short-lived processor called the ShBoom, a.k.a. the PSC1000.
> This was a weird processor that was designed to run Forth and Java
> bytecode more or less directly; it was stack-based, but also had about
> 32 registers, some of which were shared with a tiny CPU core that
> handled memory refresh. Other features included the bottom half of an
> FPU but not the top half, and an instruction encoding scheme that varied
> depending on the alignment of the instruction. OTOH the compiler was
> very fast and produced really good (and astonishingly tight!) code. I
> have no idea who made it.

I can see why that CPU was short-lived :-)

>> The one bug I spent the longest time (almost a week) to find was

Allow me to further qualify that as software bug. I've spent more
time on some hardware bugs.

>> caused by a Green Hills compiler. Since that time, I have a bit of a
>> distrust for them. Other compiler bugs I've found were mostly in very
>> obscure construct; this one was in a simple return statement.
>
> I don't know Green Hills, but I did deal with a *different* customer
> whose code was all compiled with ADS 1.2 --- a very old version of RVCT.
> I spent a happy month or so finding bugs in that, mostly due to faulty
> 64-bit arithmetic. Fun, isn't it?

I've used that compiler, not fun. The good news is that the latest
version is still ABI-compatible (with the right flags), so you can
choose to use that instead.

--
M�ns Rullg�rd
mans(a)mansr.com
From: Kenny McCormack on 16 Apr 2010 03:19
In article <Pine.LNX.4.64.1004012257170.32495(a)login01.caesar.elte.hu>,
Ersek, Laszlo <lacos(a)caesar.elte.hu> wrote:
....
>As someone suggested in your reddit submission, did you try andLinux /
>coLinux?
>
>http://andlinux.org/
>http://www.colinux.org/

Just out of curiosity, what is the difference between these two things?

I.e., andLinux seems to just be a thin wrapper around colinux. Very
thin, in fact; I can't tell what the value-added is (for andLinux).

--
(This discussion group is about C, ...)

Wrong. It is only OCCASIONALLY a discussion group
about C; mostly, like most "discussion" groups, it is
off-topic Rorsharch revelations of the childhood
traumas of the participants...

From: Ersek, Laszlo on 16 Apr 2010 08:24
On Fri, 16 Apr 2010, Kenny McCormack wrote:

> In article <Pine.LNX.4.64.1004012257170.32495(a)login01.caesar.elte.hu>,
> Ersek, Laszlo <lacos(a)caesar.elte.hu> wrote:
>>
>> http://andlinux.org/
>> http://www.colinux.org/
>
> Just out of curiosity, what is the difference between these two things?
>
> I.e., andLinux seems to just be a thin wrapper around colinux. Very
> thin, in fact; I can't tell what the value-added is (for andLinux).

I tried neither, but the opening page of andlinux.org says,

----v----
[...] andLinux is a complete Ubuntu Linux system [...]

[...] coLinux is a port of the Linux kernel to Windows [...]
----^----

lacos
First  |  Prev  | 
Pages: 1 2 3 4
Prev: [ANN] LBW 0.1: Linux Binaries on Windows
Next: IPC based on name pipe FIFO and transaction log file