On 2009-Dec-29 23:57:13 +0000, "Dr. David Kirkby" <david.kir...@onetel.net> wrote: >Peter Jeremy wrote: >Yes it does. And I can understand why, since for 99% of programs, there is no >advantage to 64-bit, but some disadvantages (larger pointers, let fit in cache >etc).
OTOH, programs doing multi-precision integer math should benefit from
64-bit arithmetic - and I would expect that at least some parts of
Sage would benefit from this.
The crucial advantage of 64-bit is (effectively) unlimited address
space - if you need to manipulate more than ~2GB data then 64-bit
is the only way to go.
x86 vs x86_64 isn't as clearcut because the x86 architecture is so
badly designed - the relatively small number and lack of orthogonality
of registers and lack of a 16-bit relative addressing mode makes the
code relatively large for a 32-bit CISC architecture (it's close in
size to the RISC SPARC).
against it.
> I would have thought the only advantage of a 32-bit would be the
>fact that gcc is less buggy.
Whilst this may be true for SPARC, I haven't seen any sign of it with x86_64.
>> Note that the current assumption that Sage is building in 32-bit mode
>> unless 'SAGE64' is set is not universally true:
>I'm not making that assumption.
Sorry. I wasn't implying that _you_ were, only that parts of Sage do.
As an example, readline-6.0.p1/spkg-install contains:
if [ "x$SAGE64" = "xyes" ] || [ "x$SAGE64" = "x1" ] ; then
echo "Building a 64-bit version of Readline"
...
else
echo "Building a 32-bit version of Readline"
fi
>If 64-bit is the default, one would not bother setting SAGE64, -m64 (or
>equivalent) flag would not get added, and the code should work. Have I
>overlooked something?
Only that parts of the code then claim to be building a 32-bit version.
So far, I haven't found any issues caused by this.
>if [ "x$SAGE64" = "xyes" ] ; then
> if [ "x`$SAGE_LOCAL/bin/testcc.sh`" = "xGCC" ] ; then
...
> elif [ "x`$SAGE_LOCAL/bin/testcc.sh`" = "xSun_Studio" ] ; then
...
> elif [ "x`$SAGE_LOCAL/bin/testcc.sh`" = "xIBM_on_AIX" ] ; then
...
You might like to look for 'case ... esac' in your sh(1) documentation.
>That way, we have as a variable (CFLAG64) in isolation, as well as in CFLAGS.
>I
>think ECL needs needed -m64 at one point during the link process, so not as a
>CFLAG.
'-m64' or similar will also need to be passed to the link step - LDFLAGS
is normally used for this.
> # -xcode=pic32 is valid on 64-bit too, despite the name.
The '32' actually refers to the size of the relocation field. There's
also pic13 on SPARC - which is significantly faster than pic32 when it
can be used. gcc also has '-fPIC' and '-fpic' for different relocation
sizes.
>Any thoughts on that?
I'm all for centralising as much as possible. My only concern is that
things like PIC choices should ideally be a combination of the compiler
(-fPIC/-fpic or -xcode=pic32/-xcode=pic13) and library (-fpic or
-xcode=pic13 if possible).
On 2009-Dec-30 00:57:27 +0000, "Dr. David Kirkby" <david.kir...@onetel.net>
wrote:
>I'm not aware the GNU linker takes any special argument for 64-bit. I know the
>Sun linker can take -64 as an option,
The cc/gcc/g++/ld/... command that actually does the linking needs the
'-64' or '-m64' flag to tell it to create a 64-bit executable, otherwise
SunStudio (at least) will default to 32-bit mode and complain about
ELF mismatches.
On 2009-Dec-30 02:17:25 +0000, "Dr. David Kirkby" <david.kir...@onetel.net>
wrote:
>I must admit, your scripting skills are a lot better than mine. What is the
>function of "E*O*F"? I'm impressed with this!
sh(1) supports an input redirection of the form '<< word' which takes
the content of the shellscript until the next occurrence of 'word' at
the beginning of a line and uses it as stdin for that command. I suggest
you read the relevant shell documentation and have a play (there are
options to control parameter expansion and leading TAB stripping).
>Anyway, I agree your revised version is much cleaner. I revised the
>C++ version in a similar way. Could you have a quick look and see if
>you see anything wrong with it.
I swapped the test for $CC and the usage report because I felt it was
more reasonable to provide a usage message if $CC wasn't set than
complain that $CC is unset.
A shorter alternative to the test would be:
: ${CC:?Sorry, you should define the environment variable CC}
>I added you as an author, as clearly you have made a major contribution to
>improving this.
Thank you.
>Are you aware of any major compilers which are not covered?
No. I have access to a Tru64 system at work but I won't be back to work
for a couple of weeks. I think that anything not currently covered is
going to need non-trivial porting effort elsewhere and detecting those
compilers can be done as part of that effort.
--
Peter Jeremy
pgpdxVISktJzQ.pgp
Description: PGP signature
