Re: Gforth and gcc "progress"

Andrew Haley wrote:
- Long long allowed us to do doubles (they broke that many years ago
on the Alpha and "fixed" it by changing the documentation, so we
have had workarounds for BUGGY_LONG_LONG for a long time).

Huh? I don't understand this remark. What broke "long long" on
Alpha? I don't imagine it was gcc.

"long long" was specified to be twice as long as "long". It makes perfect
sense to have one data type which is twice as long as the longest "native"
data type, especially to encode multiplication and division operations;
this was the original (RMS) motivation to create that data type after all.
Alpha didn't "break" that, because Alpha has a fast 64x64->128
multiplication (done in two operations, one delivering the low, one the
high result). Actually, the "right" specification of long long should
be "twice as long as intptr_t", because on a 16 bit platform, long could
already be twice as long as the largest native format.

The first GCC port to 64 bit was before, MIPS. There, they initially had a
command line switch where you can select long long to be 128 or 64 bits,
the latter for downward compatibility with people who assume long long=64
bits. The switch was dropped soon afterwards (don't know if it worked ever,
because the time we had a 64 bit MIPS station to port Gforth to, it already
stopped working).

The Alpha porting team decided to make long long=64 bits, and after we
reported that this is a bug (because it's not according to the
specification of "long long"), they changed the documentation instead
(making it "twice as long as int").

Recently, the situation improved slightly, because AMD put in a "backdoor"
to access a 128 bit data type for amd64. There, you can typedef

typedef int int128_t __attribute__((__mode__(TI)));
typedef unsigned int uint128_t __attribute__((__mode__(TI)));

and apart from converting to and from FP, it actually works (i.e. there are
TI instruction pattern; I haven't checked the FP conversions in GCC 4.2.0,
because the impact is minimal). However, I consider this more as an "easter
egg" than a real feature, as we can't depend on it - we can test if it
works, but that's all.

Unfortunately, the gcc maintainers are working hard at eliminating
these advantages, so I would love not to have to rely on gcc.

I can assure you that's not deliberate. We know that stack slot
allocation and reuse has been poor in gcc, but it is getting better.
We had some performance regressions as a result of the tree-SSA
rewrite, but we've managed to claw most of that back. It seems that
gforth has suffered more than most programs as a result of thse
changes.

Yes, but that means that you should use Gforth as regression test, because
it's one of the rare programs which actually use a significant amount of
special GCC features, has a sufficiently complex control flow (with all the
indirect branches), and other corner cases which make it a good regression
test target. Yes, I know, people like "unit tests", where each test tests
one feature in isolation, but while you ought to have these tests, you also
need the system tests. And for the system tests, you need a sufficiently
complex system with a well-defined benchmark. Using SPEC as benchmark is
not complete, because SPEC sources don't use GCC extensions.

Until 4.2.0, it was hard to see a "progress" (different from the 2.x line,
where 2.95 definitely was the best). And most of what 4.2.0 does better
than before is that the explicit register allocation doesn't conflict with
instructions using this register when it's actually dead.

--
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://www.jwdt.com/~paysan/
.

Relevant Pages

  • Re: Bad performance on alpha? (make buildworld)
    ... There are a few additional optimizations which are architecture specific, ... > GCC does. ... A quick look suggests that Alpha code generation is deficient dealing with ... instructions, this simple operation requires 17 Alpha instructions!" ...
    (freebsd-performance)
  • Re: Gforth and gcc "progress"
    ... on the Alpha and "fixed" it by changing the documentation, ... I don't imagine it was gcc. ... corner cases which make it a good regression test target. ... does better than before is that the explicit register allocation ...
    (comp.lang.forth)
  • Re: removing bcopy... because its half broken
    ... The problem is that at least some gcc versions would historically generate ... calls to "bcopy" on alpha for structure assignments. ... That's also why "bcopy" just acts like a memcpyin many cases: ... send the line "unsubscribe linux-kernel" in ...
    (Linux-Kernel)
  • Re: Gforth and gcc "progress"
    ... on the Alpha and "fixed" it by changing the documentation, ... I don't imagine it was gcc. ... allocation and reuse has been poor in gcc, ...
    (comp.lang.forth)
  • Re: nasm over gas?
    ... > than what gcc would be able to generate. ... is that for the SPECint2000 and SPECfp2000 benchmark suite, IBM's xlc was easily ... Anybody think they can consistently generate code by hand that's twice as fast? ... send the line "unsubscribe linux-kernel" in ...
    (Linux-Kernel)
Loading