Home > Archive > Fortran > January 2006 > Current status of F95 compilers for Mac/PowerPC
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Current status of F95 compilers for Mac/PowerPC
|
|
| Rich Townsend 2006-01-25, 7:10 pm |
| Hi all --
My research group is considering buying a quad-G5-core Mac, for use in
simulation work. I was wondering what the compiler situation for Macs is like.
IIRC, IBM pulled their XLF compiler in 'retaliation' for Mac deciding to switch
over to Intel chips. What players does that leave in the compiler field -- and
are they any good?
cheers,
Rich
| |
| Richard E Maine 2006-01-25, 7:10 pm |
| Rich Townsend <rhdt@barVOIDtol.udel.edu> wrote:
[about G5 Macs]
> What players does that leave in the compiler field -- and
> are they any good?
Quite a few, really.
Nag. Has been available on Macs "forever". A reliable compiler.
Absoft. I haven't used it, mostly because of its price, but I presume it
to be a quality product.
G95. I consider this to be in viable shape for even most production use.
I'm quite impressed.
GFortran. It is available, but I persnally consider it to have still had
too many bugs last time I tried it. Improving, though. Perhaps in time.
XLF. As you noted, it seems to be being withdrawn. I'm not sure of the
exact current status. I considered it a quality compiler.
I think that's all, but would be glad for corrections.
I didn't bother to mention f77 options, as you asked about f95.
--
Richard Maine | Good judgment comes from experience;
email: my first.last at org.domain| experience comes from bad judgment.
org: nasa, domain: gov | -- Mark Twain
| |
| i.chivers@ntlworld.com 2006-01-25, 7:10 pm |
| Jane Sleightholme and I maintain
details about Fortran 90, 95 compilers.
url is
http://www.kcl.ac.uk/kis/support/ci...n_resources.pdf
would it be useful to add a table with hardware, os and compiler
availability?
Richard E Maine wrote:
> Rich Townsend <rhdt@barVOIDtol.udel.edu> wrote:
> [about G5 Macs]
>
>
> Quite a few, really.
>
> Nag. Has been available on Macs "forever". A reliable compiler.
>
> Absoft. I haven't used it, mostly because of its price, but I presume it
> to be a quality product.
>
> G95. I consider this to be in viable shape for even most production use.
> I'm quite impressed.
>
> GFortran. It is available, but I persnally consider it to have still had
> too many bugs last time I tried it. Improving, though. Perhaps in time.
>
> XLF. As you noted, it seems to be being withdrawn. I'm not sure of the
> exact current status. I considered it a quality compiler.
>
> I think that's all, but would be glad for corrections.
>
> I didn't bother to mention f77 options, as you asked about f95.
>
> --
> Richard Maine | Good judgment comes from experience;
> email: my first.last at org.domain| experience comes from bad judgment.
> org: nasa, domain: gov | -- Mark Twain
| |
| Paul Van Delst 2006-01-25, 7:10 pm |
| i.chivers@ntlworld.com wrote:
> Jane Sleightholme and I maintain
> details about Fortran 90, 95 compilers.
>
> url is
>
> http://www.kcl.ac.uk/kis/support/ci...n_resources.pdf
Is the SGI entry correct? Last time I checked (i.e running my code on an SGI), the MIPSpro
f90 compiler didn't like some f95 constructs (specifically named end interface statements
for operators).
The only SGI reference to Fortran95 I could find was via third party compilers,
specifically NAG:
http://www.sgi.com/products/appsdir...s/n/819383.html
cheers,
paulv
>
> would it be useful to add a table with hardware, os and compiler
> availability?
>
> Richard E Maine wrote:
>
>
>
--
Paul van Delst
CIMSS @ NOAA/NCEP/EMC
| |
| hrh1818 2006-01-25, 7:10 pm |
| Intel says they will sell a Fortran compiler for Intel dual core Macs
this summer. See
http://news.com.com/ Details+on+Int..._3-6028015.html
for more information..
Howard
Rich Townsend wrote:
> Hi all --
>
> My research group is considering buying a quad-G5-core Mac, for use in
> simulation work. I was wondering what the compiler situation for Macs is like.
> IIRC, IBM pulled their XLF compiler in 'retaliation' for Mac deciding to switch
> over to Intel chips. What players does that leave in the compiler field -- and
> are they any good?
>
> cheers,
>
> Rich
| |
| Rich Townsend 2006-01-25, 7:10 pm |
| hrh1818 wrote:
> Intel says they will sell a Fortran compiler for Intel dual core Macs
> this summer. See
> http://news.com.com/ Details+on+Int..._3-6028015.html
> for more information..
>
> Howard
Thanks for the info. However, I need to stick to the G5 platform, even though
it's being phased out. I've already got a quad Opteron system, and it beats the
pants off comparable Intel systems; from benchmarks I've seen, I expect even
better performance from a G5 system.
cheers,
Rich
| |
| Ron Shepard 2006-01-26, 3:59 am |
| In article <dr972b$nor$1@scrotar.nss.udel.edu>,
Rich Townsend <rhdt@barVOIDtol.udel.edu> wrote:
> hrh1818 wrote:
>
> Thanks for the info. However, I need to stick to the G5 platform, even though
> it's being phased out. I've already got a quad Opteron system, and it beats
> the
> pants off comparable Intel systems; from benchmarks I've seen, I expect even
> better performance from a G5 system.
Each core in the quad G5 is 10 GFLOP/s peak with 64-bit arithmetic,
and four cores give you 40 GFLOP/s peak.
One thing that is not clear regarding fortran compilers is which
ones support 64-bit addressing. The Absoft compiler does, but there
are some quirks. For example, the following code
program big
integer, parameter :: i8=selected_int_kind(16)
integer(i8), parameter :: n=5000_i8 * 1000_i8 * 1000_i8
integer(i8) :: i ! default
integer, allocatable :: ia(:)
allocate( ia(n) )
do i = 1_i8, n
ia(i) = i
enddo
write(*,*) ia(1), ia(n)
end program big
does not compile with a static allocation of the array ia(n), it
must be allocatable. Furthermore, the do loop will not compile
because of the error:
$ f95 -m64 big.f90
do i = 1_i8, n
^
cf90-1082 f90fe64: ERROR BIG, File = big.f90, Line = 7, Column = 4
The iteration count is too large.
If you change the parameter "n" to a smaller value, then it does
work. BTW, you can assign the value of "n" in the normal way, I
used the above expression just to make it easier to count the zeros.
Apparently, the do loop trip count is done with 32-bit integers, and
you cannot force it to use 64-bit integer arithmetic. If you remove
the do-loop and just assign the array elements, then it compiles and
works as expected.
I have used computers in the past with 64-bit integers (e.g. Crays)
where this was not a problem. The Absoft compiler has a Cray
heritage, so it is a little surprising to me that the above code
would have problems. BTW, when it does work, the above code works
only on a G5 and MacOSX 10.4 or later. On earlier OS versions or
with old hardware, you cannot allocate the large array.
The IBM xlf compiler does not support 64-bit addressing. They are
no longer marketing the compiler directly, so it is not clear if
they will update it to be compatible with the 64-bit addressing
allowed by macosx 10.4. Absoft still sells (and apparently still
supports) the IBM compiler on Macs.
Can anyone give any info on the other Mac fortran compilers
regarding 64-bit addressing?
$.02 -Ron Shepard
| |
|
| Hi Ron,
'64bit' g95 on opteron (http://ftp.g95.org/g95-x86_64-64-linux.tgz)
compiles and runs the above program (also if ia is not an allocatable).
There was some discussion about 64bit g95 for Mac in the newsgroup
(http://groups.google.com/group/gg95) so I assume that this is
working/going to work really soon.
Just as an aside, the program you've posted is non-standard if the
default integer is 32bit, since ia(i)=i is out of range. Declaring ia
integer*8 solves the problem, but makes testing a little more demanding
;-)
Joost
| |
| i.chivers@ntlworld.com 2006-01-26, 7:02 pm |
| Thanks for the correction. I took the text from Mike Metcalf's
file and haven't verified all of the entries.
I'll change the entry.
Jane and I obviously don't use all of
these compilers :-)
| |
| Ron Shepard 2006-01-26, 7:02 pm |
| In article <1138265799.159355.141760@g43g2000cwa.googlegroups.com>,
"Joost" <jv244@cam.ac.uk> wrote:
> Just as an aside, the program you've posted is non-standard if the
> default integer is 32bit, since ia(i)=i is out of range. Declaring ia
> integer*8 solves the problem, but makes testing a little more demanding
> ;-)
Oops, you are right. I was experimenting to see what would and
would not work, and my last iteration did not have the declaration
that I had intended to post.
integer(i8), allocatable :: ia(:)
One other comment about this, the absoft compiler also has an option
to change the default integer type to 64-bit, and this also is
insufficient allow the code to execute correctly with static
allocation of ia(). I assume that these are bugs related to heap
vs. stack allocation of the large array, and that they will be fixed
eventually.
$.02 -Ron Shepard
| |
| Richard E Maine 2006-01-26, 7:02 pm |
| Ron Shepard <ron-shepard@NOSPAM.comcast.net> wrote:
> The IBM xlf compiler does not support 64-bit addressing. They are
> no longer marketing the compiler directly, so it is not clear if
> they will update it to be compatible with the 64-bit addressing
> allowed by macosx 10.4. Absoft still sells (and apparently still
> supports) the IBM compiler on Macs.
I'm puzzled by the "no more" bit in the above. To my possibly faulty
knowledge, IBM never directly marketed their OS-X version of xlf
directly, but did so only though Absoft. I remember thinking this very
strange, particularly since Absoft was a direct competitor. I asked my
IBM contacts about it, but they are all technical types and had no more
clue about the marketing decisions than I did.
--
Richard Maine | Good judgment comes from experience;
email: my first.last at org.domain| experience comes from bad judgment.
org: nasa, domain: gov | -- Mark Twain
| |
| hrh1818 2006-01-27, 3:59 am |
| Rich Townsend wrote:
> hrh1818 wrote:
>
> Thanks for the info. However, I need to stick to the G5 platform, even though
> it's being phased out. I've already got a quad Opteron system, and it beats the
> pants off comparable Intel systems; from benchmarks I've seen, I expect even
> better performance from a G5 system.
Because you want to use a G5 system it doesn't automatically rule out
an Intel Fortran compiler. The Intel Fortran compiler can be used to
produce Universal Binaries. See following quote extracted from the
article I referenced.
"The toolchain integrates into Apple's Xcode IDE, meaning the Intel
compilers can be used in the production of Universal
Binaries--applications packaged with code for both Power and Intel
architecture machines."
However, the article leaves me  as to whether the Intel Fortran
compiler can produce 64 bit code or address more than 4GB of memoy
when used with Apple's Xcode 2 IDE. Hence, even though the Intel
Fortan compiler can be used to produce Universal Binaries it still very
well might be unsuitable for your application.
Howard
> cheers,
>
> Rich
| |
| Ron Shepard 2006-01-27, 3:59 am |
| In article <1h9rj2o.1sxwkks1b8w83gN%nospam@see.signature>,
nospam@see.signature (Richard E Maine) wrote:
>
> I'm puzzled by the "no more" bit in the above. To my possibly faulty
> knowledge, IBM never directly marketed their OS-X version of xlf
> directly, but did so only though Absoft.
You could download the beta version of the compiler directly from
the IBM web site (for free). Then when it first went commercial, I
thought you could still order the compiler from that same web site
(with a credit card). I did not do this, I ended up ordering it
from Absoft, so I could be wrong, but that is the way I remembered
it.
BTW, I checked the absoft web site a few minutes ago, and it appears
that they too have stopped selling the MacOSX version of the
compiler. I'm pretty sure it was there as recently as a couple of
w s ago. They still sell the PPC linux version of xlf.
$.02 -Ron Shepard
| |
| Jeffrey Jones 2006-01-27, 3:59 am |
| In article <1138338456.805999.221390@z14g2000cwz.googlegroups.com>,
hrh1818 <howardrh@westerncom.net> wrote:
> Because you want to use a G5 system it doesn't automatically rule out
> an Intel Fortran compiler. The Intel Fortran compiler can be used to
> produce Universal Binaries. See following quote extracted from the
> article I referenced.
>
> "The toolchain integrates into Apple's Xcode IDE, meaning the Intel
> compilers can be used in the production of Universal
> Binaries--applications packaged with code for both Power and Intel
> architecture machines."
I think you are probably misinterpreting this statement. I think they
mean the Intel compilers would be integrated into Xcode to produce only
the Intel portion of the Universal Binary. The PPC code would still
come from Apple's gcc.
| |
| Richard Maine 2006-01-27, 3:59 am |
| hrh1818 <howardrh@westerncom.net> wrote:
> Because you want to use a G5 system it doesn't automatically rule out
> an Intel Fortran compiler. The Intel Fortran compiler can be used to
> produce Universal Binaries.
In addition to the other uncertainties you mentioned, note that
producing universal binaries does not imply that it itself is one. That
is really two unrelated issues. So it is possible that it might be able
to produce PPC code, but still only run on Intels.
Also I note the phrase about being able to be "used in the production"
of universal binaries. I don't know whether it is my language lawyer
ears or my skeptical consumer ears, but I notice that didn't actually
say that this compiler could produce both Intel and PPC code. Perhaps it
can, but that blurb didn't quite exactly say that. Perhaps, for example,
it can only produce the Intel part, but can put that part in a universal
binary if you get the PPC part from elsewhere. I don't know enough about
this universal binary business to know whether what I just said even
makes any sense. :-)
Or maybe all is ok. But I'd ask more pointed questions before investing
money on the assumption.
--
Richard Maine | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle | -- Mark Twain
| |
| awgreynolds@earthlink.net 2006-01-27, 7:01 pm |
| I have been using Fortran on my PowerMacG5 for a couple years now, and
I can second all of Richard's points. I would add one possibilty. If
you're more interested in the G5 architecture than MacOSX, you might
look into installing (dual boot) YellowDogLinux.com's Y-HPC. IBM does
sell a more advanced version of XLF for this platform (9.1 with 64-bit
addressing for $999). I would bet this combination easily out-performs
MacOSX with any of the other compilers.
Al Greynolds
www.ruda.com
| |
| Ron Shepard 2006-01-27, 7:01 pm |
| In article <1138373900.558699.94790@o13g2000cwo.googlegroups.com>,
awgreynolds@earthlink.net wrote:
> I have been using Fortran on my PowerMacG5 for a couple years now, and
> I can second all of Richard's points. I would add one possibilty. If
> you're more interested in the G5 architecture than MacOSX, you might
> look into installing (dual boot) YellowDogLinux.com's Y-HPC. IBM does
> sell a more advanced version of XLF for this platform (9.1 with 64-bit
> addressing for $999). I would bet this combination easily out-performs
> MacOSX with any of the other compilers.
It makes you wonder why IBM never supported 64-bit MacOSX 10.4 last
year. They had the technology (and used it on AIX on their own
POWER architecture too), but they weren't aggressive with marketing
it to MacOSX where it really counted. This was not really a matter
of competition, Macs don't really compete for the same customers as
their linux or AIX servers.
$.02 -Ron Shepard <--another missed opportunity,
clearest with hindsight
| |
| hrh1818 2006-01-27, 9:57 pm |
| Richard Maine wrote:
> hrh1818 <howardrh@westerncom.net> wrote:
>
>
> In addition to the other uncertainties you mentioned, note that
> producing universal binaries does not imply that it itself is one. That
> is really two unrelated issues. So it is possible that it might be able
> to produce PPC code, but still only run on Intels.
>
> Also I note the phrase about being able to be "used in the production"
> of universal binaries. I don't know whether it is my language lawyer
> ears or my skeptical consumer ears, but I notice that didn't actually
> say that this compiler could produce both Intel and PPC code. Perhaps it
> can, but that blurb didn't quite exactly say that. Perhaps, for example,
> it can only produce the Intel part, but can put that part in a universal
> binary if you get the PPC part from elsewhere. I don't know enough about
> this universal binary business to know whether what I just said even
> makes any sense. :-)
>
The following is based on Chapter 4 of "The Mac Xcode 2 Book". The
Xcode IDE compilers come from the GNU compiler collection and are
maintained by Apple. The GNU compilers are split into two parts. One
a language specific front end that translate a high level language into
an intermediate abstract syntax tree form, which represents the
program's structure in a language neutral way. All of the compilers
in GNU's compiler collection produce a common intermediate language.
The GNU compiler collection back end then converts the tree into a set
of instructions the target CPU can understand. The book shows a
diagram of the GNU compiler collection producing either Pentium IV or
Power PC G5 code. Up until the dual core Intel iMac Apple only
supplied the C-related front ends and the power PC back end from the
GNU compiler collection with the Xcode IDE. Third party Fortran,
Pascal and Ada compilers could also be obtained for use with Apple's
Xcode's IDE.
Hence using GNU's compiler tools it was easy for Apple to add a back
end for Intel CPUs and produce Universal Binaries. Therefor all
Intel needs to do, is build a Fortran compiler that produces a language
neutral output that is compatible with GNU's compiler collection. The
back ends in GNU's compiler collection then can produce Universal
Binaries.
Jeffrey and Richard, I hope this explains how the Intel Fortran
compilers can be used to produce Universal binaries. If not fire away
I will rtry to answer your questions.
Howard.
> Or maybe all is ok. But I'd ask more pointed questions before investing
> money on the assumption.
>
> --
> Richard Maine | Good judgement comes from experience;
> email: last name at domain . net | experience comes from bad judgement.
> domain: summertriangle | -- Mark Twain
| |
| Richard Maine 2006-01-28, 3:57 am |
| hrh1818 <howardrh@westerncom.net> wrote:
> Jeffrey and Richard, I hope this explains how the Intel Fortran
> compilers can be used to produce Universal binaries. If not fire away
> I will rtry to answer your questions.
No, really it doesn't explain how the Intel Fortran compilers *CAN* be
so used. It explains how some compilers might be usable that way.
Nothing specifically says that this is the only way anything can
possibly work or that the Intel compiler specifically does this.
No,I don't have questions for you. Why would I? You would be the wrong
person for me to ask any such questions of. You aren't going to be able
to give definitive answers - just speculation. Possibly well-informed
speculation, and possibly even correct speculation. But you aren't going
to actually be able to give a definitive answer.
If I wanted to ask that question, there are people who *DO* work for
Intel and regularly post here. I'd ask them and get a real answer
instead of asking someone else and get speculation.
--
Richard Maine | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle | -- Mark Twain
| |
| Gary L. Scott 2006-01-28, 3:57 am |
| hrh1818 wrote:
> Richard Maine wrote:
>
>
> The following is based on Chapter 4 of "The Mac Xcode 2 Book". The
> Xcode IDE compilers come from the GNU compiler collection and are
> maintained by Apple. The GNU compilers are split into two parts. One
> a language specific front end that translate a high level language into
> an intermediate abstract syntax tree form, which represents the
> program's structure in a language neutral way. All of the compilers
> in GNU's compiler collection produce a common intermediate language.
> The GNU compiler collection back end then converts the tree into a set
> of instructions the target CPU can understand. The book shows a
> diagram of the GNU compiler collection producing either Pentium IV or
> Power PC G5 code. Up until the dual core Intel iMac Apple only
> supplied the C-related front ends and the power PC back end from the
> GNU compiler collection with the Xcode IDE. Third party Fortran,
> Pascal and Ada compilers could also be obtained for use with Apple's
> Xcode's IDE.
>
> Hence using GNU's compiler tools it was easy for Apple to add a back
> end for Intel CPUs and produce Universal Binaries. Therefor all
> Intel needs to do, is build a Fortran compiler that produces a language
> neutral output that is compatible with GNU's compiler collection. The
> back ends in GNU's compiler collection then can produce Universal
> Binaries.
>
> Jeffrey and Richard, I hope this explains how the Intel Fortran
> compilers can be used to produce Universal binaries. If not fire away
> I will rtry to answer your questions.
? the binaries are definitely not "universal"...maybe a better term is
needed?
>
> Howard.
>
>
>
>
>
--
Gary Scott
mailto:garyscott@ev1.net
Fortran Library: http://www.fortranlib.com
Support the Original G95 Project: http://www.g95.org
-OR-
Support the GNU GFortran Project: http://gcc.gnu.org/fortran/index.html
Why are there two? God only knows.
If you want to do the impossible, don't hire an expert because he knows
it can't be done.
-- Henry Ford
| |
| Brooks Moses 2006-01-28, 3:57 am |
| Gary L. Scott wrote:
> hrh1818 wrote:
>
> ? the binaries are definitely not "universal"...maybe a better term is
> needed?
"Universal binary" is Apple's official term for the things; I don't
think quibbling with the term is going to do much good.
- Brooks
--
The "bmoses-nospam" address is valid; no unmunging needed.
| |
| Gary L. Scott 2006-01-28, 7:01 pm |
| Brooks Moses wrote:
> Gary L. Scott wrote:
>
>
>
> "Universal binary" is Apple's official term for the things; I don't
> think quibbling with the term is going to do much good.
Doesn't serve improve my impression of Apple if so, though.
>
> - Brooks
>
>
--
Gary Scott
mailto:garyscott@ev1.net
Fortran Library: http://www.fortranlib.com
Support the Original G95 Project: http://www.g95.org
-OR-
Support the GNU GFortran Project: http://gcc.gnu.org/fortran/index.html
Why are there two? God only knows.
If you want to do the impossible, don't hire an expert because he knows
it can't be done.
-- Henry Ford
| |
| Ron Shepard 2006-01-28, 7:01 pm |
| In article <11tn3umm0mmu1b4@corp.supernews.com>,
"Gary L. Scott" <garyscott@ev1.net> wrote:
[color=darkred]
They had already used the term "fat binary" for the similar scheme
in 1994 were an application contained both 68K and PPC executable
code. A "universal" binary can contain 32-bit PPC code, PPC code
with altivec, PPC code without altivec, 64-bit PPC code, 32-bit
intel code, and 64-bit intel code. Many of us were hoping that
Apple would skip over the 32-bit intel chips for simplicity, but
they didn't. Also, this same idea was used by Next, where an
application could include also PA-RISC, MIPS, and Sparc binaries.
Having said all of this, I don't know the answer to the question
about the intel fortran compiler. I think, but I'm not certain,
that the intel compiler will generate only x86 code (perhaps several
types, 32-bit, 64-bit, with and without SSE3, etc.), and that a
separate compiler will be necessary to generate the various PPC
binaries that will be combined in the "universal binary" format.
Other than interfacing to the same system APIs, I do not believe
that much, if any, interoperability is required between the various
compilers used to build these universal binaries, it is really just
a way to package several independent executables into a single
application. I doubt that this will much affect code that is
distributed in source form, it is mainly related to packaged
binary-only applications.
$.02 -Ron Shepard
| |
| Gary L. Scott 2006-01-28, 7:01 pm |
| Ron Shepard wrote:
> In article <11tn3umm0mmu1b4@corp.supernews.com>,
> "Gary L. Scott" <garyscott@ev1.net> wrote:
>
>
>
>
> They had already used the term "fat binary" for the similar scheme
> in 1994 were an application contained both 68K and PPC executable
> code. A "universal" binary can contain 32-bit PPC code, PPC code
> with altivec, PPC code without altivec, 64-bit PPC code, 32-bit
> intel code, and 64-bit intel code. Many of us were hoping that
> Apple would skip over the 32-bit intel chips for simplicity, but
> they didn't. Also, this same idea was used by Next, where an
> application could include also PA-RISC, MIPS, and Sparc binaries.
>
> Having said all of this, I don't know the answer to the question
> about the intel fortran compiler. I think, but I'm not certain,
> that the intel compiler will generate only x86 code (perhaps several
> types, 32-bit, 64-bit, with and without SSE3, etc.), and that a
> separate compiler will be necessary to generate the various PPC
> binaries that will be combined in the "universal binary" format.
> Other than interfacing to the same system APIs, I do not believe
> that much, if any, interoperability is required between the various
> compilers used to build these universal binaries, it is really just
> a way to package several independent executables into a single
> application. I doubt that this will much affect code that is
> distributed in source form, it is mainly related to packaged
> binary-only applications.
>
> $.02 -Ron Shepard
Maybe then, "multiple processor binary" or "dual processor binary" (in
aerospace, it would of course get an acronym, DPB, and a file extension
of .dpb). Certainly not universal. No big deal, just seemed sort of
obvious.
--
Gary Scott
mailto:garyscott@ev1.net
Fortran Library: http://www.fortranlib.com
Support the Original G95 Project: http://www.g95.org
-OR-
Support the GNU GFortran Project: http://gcc.gnu.org/fortran/index.html
Why are there two? God only knows.
If you want to do the impossible, don't hire an expert because he knows
it can't be done.
-- Henry Ford
|
|
|
|
|