Re: Gforth and gcc "progress"

Andrew Haley <andrew29@xxxxxxxxxxxxxxxxxxxxxxx> writes:
Anton Ertl <anton@xxxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
"slava@xxxxxxxxx" <slava@xxxxxxxxx> writes:
Why does gforth rely on gcc at all?

We want portability and speed. Gcc used to have outstanding
advantages there:

- Labels-as-values allowed us to do threaded code (factor of 2 over
switch dispatch) and dynamic superinstructions (another factor of 2).

- Explicit register allocation allowed us to get decent register
allocation.

- 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 documented as being twice as long as "long int". On
Alpha it was not.

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.

Well, I think it's an attitude problem. My impression is that any
code that's not ANSI C is considered unworthy (including code using
documented GNU C extensions), and reporters of bugs in this area are
made to feel unwelcome, e.g., by "resolving" a bug report as "invalid"
in less time than it took to prepare the bug report (PR25285);
comments like

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15242#c2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15242#c7
<121j5paro87li96@xxxxxxxxxxxxxxxxxx> ff.

also contribute to my impression.

We know that stack slot
allocation and reuse has been poor in gcc, but it is getting better.

We don't care much for that (might change when callbacks are used
more, though), and in any case, gcc never was great in that respect.

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.

Well, it's not all doom and gloom. Bernd has found an explicit
register allocation that works well with gcc-4.2.0 (but not 4.1);
scaling the results to our 2.2GHz Athlon 64X2 gives:

sieve bubble matrix fib
0.208 0.296 0.108 0.328 gcc 2.95.4 20011002 (Debian prerelease)
0.264 0.344 0.120 0.360 gcc 3.4.6 (Debian 3.4.6-5)
0.384 0.432 0.296 0.520 gcc 4.1.2 (default configuration)
0.476 0.748 0.280 0.476 gcc 4.1.2 STACK_CACHE_DEFAULT_FAST=0
0.364 0.524 0.288 0.472 gcc 4.1.2 STACK_CACHE_DEFAULT_FAST=0 condbranch_opt=0
0.240 0.331 0.113 0.342 gcc 4.2.0

Still not quite in the 2.95 leage, but better than 3.4.

- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2007: http://www.complang.tuwien.ac.at/anton/euroforth2007/
.

Relevant Pages

  • 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: Gforth and gcc "progress"
    ... on the Alpha and "fixed" it by changing the documentation, ... I don't imagine it was gcc. ... register allocation that works well with gcc-4.2.0; ...
    (comp.lang.forth)
  • Re: Code density and performance?
    ... Heck, IPF memory requirements make ... It wasn't when the Alpha was designed. ... |> You mean the "POSIX" documentation, ... |>> You may regard breaking standards without even documenting the ...
    (comp.arch)
  • Alpha Server 1000A OS install and/or documentation help
    ... I've tried every other avenue for documentation for the Alpha Server ... HP's WEB site seems to be just a circular queue ("...didn't ... available, Install and Upgrade Supplemental Guide, for VAX/VMS OS 6.2. ...
    (comp.os.vms)
  • Re: xmalloc string functions
    ... The documentation tells me how the library is _supposed_ to work. ... it is _supposed_ to terminate the application on allocation ... Thus, if I write code according to how glib is _supposed_ to work, I will ... So it either fails on allocation failure, which, frankly, I find ...
    (comp.lang.c)