From: Wes Nakamura <wknaka@...>
Date: 2000-04-30T02:02:42-07:00
Subject: [ruby-talk:02609] linux-alpha/ccc / syntax


Hi, 

I've been working on getting ruby to compile on linux/alpha using
Compaq's (DEC's) ccc compiler instead of gcc for higher performance. 

To get ruby 1.4.4 to compile with ccc, in eval.c line 726 in rb_eval's
prototype, the NODE* must be changed to NODE* volatile; the same for
line 732 in module_setup.  I believe this is also the case with 1.5.

Attempting to load a (shared object) module causes an unaligned trap
followed by a segmentation violation.  Normally the kernel handles
unaligned accesses gracefully, but in this case it doesn't.  I've traced
it to do_entUnaUser in the kernel, which is supposed to handle the
unaligned accesses, and apparently _dl_relocate_object, which appears to
be in libc.  (glibc 2.1.1 in this case)

configure --without-gcc sets compilation to use -g.  I've determined
that the flags used for the compilation of the modules affects the
loading.  Using -O2 instead of -g causes everything to work fine (ruby
itself can still be compiled with -g and everything's okay).  I'm not
sure what exactly the relationship is between ccc and egcs (ccc requires
that you have egcs installed), but I would assume that is a bug or some
other kind of incompatibility with ccc or egcs.  This is with ccc
version 6.2.9.002 and egcs 1.1.2. 

Well, now that I've got a working ccc-compiled ruby, is there a
benchmark (rubystone? - nice name) to compare performance differences
between the ccc and gcc compiled versions? 


Also, I've got a syntax question.  Using () across multiple lines for
method calls allows you to continue the parameter list without a \.
However, it doesn't work for grouping/precedence.

E.g. you can do:

object.method(arg0,
              arg1)
              
but not:

if (this
    || that)

You *can* do

if (this ||
    that) 

but I'm wondering if there is a problem with allowing the previous
version to work as well.  In python this allows you to avoid using \
quite often. 

Wes.