 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thorsten Froehlich wrote:
> BTW, does the AIX compiler still generate XCOFF files? And does it have a
> 32-bit XCOFF option? I am asking because if it does, could you run the
> 3.1gx code through it? I can link XCOFF files on the Mac and maybe xlc code
> is already faster than CodeWarrior code - having the compiled code in XCOFF
> format would make things a lot easier than using the Metaware compiler...
It produces 32 bit XCOFF object files and can run the code as well. I compiled
it for Power processors but I can compile it for PowerPC as well but I don't
think it does 750 or 7400 code, just 604 code.
I tried to compile it with 64 bits but it doesn't link, I think it is because
the machine the compiler runs on isn't a Power machine.
And I tried to get my hands on a Itanium machine but no luck so far..... :(
Thomas
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3B6### [at] gmx net> , Thomas <tho### [at] gmxnet> wrote:
> It produces 32 bit XCOFF object files and can run the code as well. I compiled
> it for Power processors but I can compile it for PowerPC as well but I don't
> think it does 750 or 7400 code, just 604 code.
Hmm, 604 should do fine. The FPUs in the 604 and 7xx PowerPCs are not much
different in execution time as that it should be a major problem, I think.
Only that the 604 can dispatch 4 (AFAIK) instructions per clock cycle while
all 7xx except the 7450 can only dispatch three instructions per clock
cycle. But I suspect the major problem with CodeWarrior is that it doesn't
schedule FPU instructions at all (i.e. interleave FPU and integer
instructions, not even float load/stores), so any improvement in that part
of the code should outweigh the possible slowdowns in the rare case that
four instructions can really be dispatched in one cycle...
Thorsten
PS: In theory Macs should emulate all Power 32 bit instructions. Of course
it would slow down things :-)
____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde
Visit POV-Ray on the web: http://mac.povray.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Are you sure that the ABI of AIX and Mac is similar enough to make sure that it
doesn't cause any problems? The PowerPC ABI for embedded application is different
AFAIK ( the one generated by the Metaware compiler)
Thorsten Froehlich wrote:
> IPS: In theory Macs should emulate all Power 32 bit instructions. Of course
> it would slow down things :-)
Interesting that it does, but I'm pretty sure I can get it to make pure PowerPC
stuff.
Thomas
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3B6A8F00.35718D67@gmx.net> , Thomas <tho### [at] gmxnet> wrote:
> Are you sure that the ABI of AIX and Mac is similar enough to make sure that
> it doesn't cause any problems? The PowerPC ABI for embedded application is
> different AFAIK ( the one generated by the Metaware compiler)
When Apple ported Mac OS from 68K to PowerPC they used IBM compilers and AIX
at first. For this reason the format is the same. In fact it is so similar
that I can still generate code for Power processors with Apples own PowerPC
compiler (which is unfortunately not really supported anymore). If I had
the right libraries I could probably even compile and link AIX applications
on a Mac!
Thorsten
____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde
Visit POV-Ray on the web: http://mac.povray.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Just to be be sure, if you would send me just one of the xcoff files I could
run it through a Apple xcoff viewer and see if it accepts it.
Thorsten
____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde
Visit POV-Ray on the web: http://mac.povray.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thomas wrote:
>
> Hi,
>
> I finally managed to get the IBM xlc compiler on AIX to compile povray
> (See my note in povray.unix) and I was going through the options and saw
> that I can generate 64 bit code and 32 bit code, any clue if this will
> make a difference to pov's performance? Or will will it have any other
> side effect's?
There are very tricky things done with 32 bits integers and floats in
the octree storage code.
Unfortunately I only got 32-bit processors, and nobody completed the
alpha port of PvMegaPOV, so I can't tell you more about this particular
issue in modern machines.
--
__ __ __ __ _
| | / \ / / |_ / |/
\/\/ \__/ /_ /_ |__ \_ |\
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thorsten Froehlich wrote:
>
> BTW, I am not sure if you aware of it, but C/C++ "int" should always be 32
> bit and "long" should always be 64 in current implementations by common
> agreement.
What is common agreement? That my ints are 32 bit _and_ my longs
are 32 bit (and I guess so are yours). I still have to see an
implementation (on common machines, i.e. Linux/Windows/Apple,...)
that has 64 bit longs (apart from __int64 and the like).
> An implementation that uses 64 bit "int" types is not very
> common to say the least. For a full reference (not the ultimate one, but
> the one that I could find in 10 seconds), see
> <http://www.opengroup.org/public/tech/aspen/lp64_wp.htm>
If the machine architecture is 64 bits, then integers will be
exactly that (and stay equal in size to longs, as they are
on todays 32 bit platforms).
Markus
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Markus Becker <bec### [at] aicossde> wrote:
: I still have to see an
: implementation (on common machines, i.e. Linux/Windows/Apple,...)
: that has 64 bit longs (apart from __int64 and the like).
Is UltraSparc a common machine?
: If the machine architecture is 64 bits, then integers will be
: exactly that (and stay equal in size to longs, as they are
: on todays 32 bit platforms).
The UltraSparc and Alpha processors are 64-bit, and both have 32-bit ints
and 64-bit longs.
--
#macro N(D,I)#if(I<6)cylinder{M()#local D[I]=div(D[I],104);M().5,2pigment{
rgb M()}}N(D,(D[I]>99?I:I+1))#end#end#macro M()<mod(D[I],13)-6,mod(div(D[I
],13),8)-3,10>#end blob{N(array[6]{11117333955,
7382340,3358,3900569407,970,4254934330},0)}// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3B6FF732.E94C5F53@aicoss.de> , Markus Becker <bec### [at] aicossde>
wrote:
> What is common agreement?
You did check out the link, didn't you? For an "official" summary you may
want to read <http://www.opengroup.org/public/tech/aspen/aspenf.htm>. To me
this sounds like a common agreement, doesn't it?
> That my ints are 32 bit _and_ my longs
> are 32 bit (and I guess so are yours). I still have to see an
> implementation (on common machines, i.e. Linux/Windows/Apple,...)
> that has 64 bit longs (apart from __int64 and the like).
I was talking about 64 bit architectures!
> If the machine architecture is 64 bits, then integers will be
> exactly that (and stay equal in size to longs, as they are
> on todays 32 bit platforms).
Nope. It will be 32 bit for int and 64 bit for long on all professional
Unix versions by default (of course taking into account backward
compatibility issues). I think (from the link I cited) DEC/Compaq, HP, IBM,
Intel, Novell, NCR, and Sun are sufficient to call it common (together at
least 99% market share of 64 bit workstations and servers)...
Thorsten
____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde
Visit POV-Ray on the web: http://mac.povray.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
[also replying to warp]
Thorsten Froehlich wrote:
>
> > What is common agreement?
>
> You did check out the link, didn't you? For an "official" summary you may
> want to read <http://www.opengroup.org/public/tech/aspen/aspenf.htm>. To me
> this sounds like a common agreement, doesn't it?
This is indeed common agreement. In the unix world. This has
nothing to do with any standards regarding C and/or C++.
The only thing that is (cross-platform) guaranteed is:
sizeof(char)<=sizeof(short)<=sizeof(int)<=sizeof(long)
and
sizeof(char)==1
Decide for your self what this can mean. And I have heard
that in the Wintel world (wich also has a 64 Bit architecture
available) ints remain 32 bit. This is also common agreement.
And, as I take it, the same as in the unix world. But it
is not guaranteed.
> I was talking about 64 bit architectures!
I forgot that eg. Alpha is 64 bit.
Markus
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
