On 08/ 8/10 05:09 AM, Jason B Hill wrote:
In your opinion, is it better to leave the current behavior of including
fpu.c on Itanium Linux systems, or just remove that since it will be safer?
Be a bit careful with the language here. If someone has an older
(pre-Montecito) Itanium, then from what I understand it is perfectly
plausible that they may either purposely or accidentally install an
x86-based Linux. I.e., uname -m and uname -p will mismatch. But yes, for
uname -m equal to ia64, I would argue that including fpu.c is not safe.
You agree with me then - it is unsafe to include fpu.c.
The sympow code works on at least some systems (e.g. SPARC) without including
fpu.c. I don't know whether fpu.c speeds things up or not, but its clearly not
necessary to include it.
Including fpu.c on systems which don't support the instructions are going to
lead to undefined behavior. The worst that could happen on a system which does
support the instruction is a slowdown by not including fpu.c
In
my experience, I don't know of a way to reliably prune the /proc/cpuinfo
file on Itaniums in order to determine the hardware support for x86/ia32.
(/proc/cpuinfo for Itaniums and older Opterons appear to be problem childs.)
It's better to be safe that sorry I think in this case.
IMHO, It would have been simpler to just assume 'rm', 'grep', uname and
other similar programs just exist.
At least uname -m appears to be standard
The unusual thing with the Configure script for sympow is that it checks for
what I personally consider unnecessary things like 'sh'.
The script starts with:
#! /bin/sh
then further down the script it checks if 'sh' exists. Well, if sh did not
exist, the script would not run!
If you take a brief look at
http://boxen.math.washington.edu/home/kirkby/Configure
you will see what I mean. The only one that need testing are the C compiler and
'gp'. (William has re-written this script a bit, so it uses gcc not cc).
But 'uname' must exist on any true Unix operating system, as it is defined by
the POSIX standard for Unix. So must the -m option work on uname. But some
options like -p are not defined by POSIX and don't work on all systems.
http://www.opengroup.org/onlinepubs/9699919799/utilities/uname.html
has the valid options for uname
-a
Behave as though all of the options -mnrsv were specified.
-m
Write the name of the hardware type on which the system is running to
standard output.
-n
Write the name of this node within an implementation-defined communications
network.
-r
Write the current release level of the operating system implementation.
-s
Write the name of the implementation of the operating system.
-v
Write the current version level of this release of the operating system
implementation.
but uname -p -i and -M don't
appear to be so. E.g., newer Linux, Mac OS-X, several variants of BSD and
IRIX (OK... the last one is a stretch), don't support some of the latter
options... while I can find at least one OS that does any of them.
I personally only ever use the POSIX options, unless I know that I'm using a
system which supports a particular option, and even then I try to avoid it. (I
know for a fact -p is not supported on HP-UX)
I think the author was correct to use 'uname -m', but I can't actaully see the
point of testing if 'sh', 'rm', 'grep', 'sed' and 'uname' exist. All those are
defined by POSIX.
But the real problem I have with this is the invalid C code, as despite an
attempt to convert this to C, it is not behaving. It builds, but does not work
properly on Solaris x86, but given the code is not valid C, its hard to know how
to re-write it to make it work.
Jason
Dave
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
