标签: powerpc

由于Apple只发布带有Xcode4的SDK 10.6,因此用Xcode4开发PPC应用程序变得不可能.虽然可以使用Xcode4开发应用程序,也可以在10.5甚至10.4系统上运行(通过选择SDK 10.6,但部署目标10.5或10.4),但它们只能在Intel Mac上运行,因为您至少需要SDK 10.5才能运行构建PPC应用程序.

此外,还有一些罕见的情况,您需要在10.6之前构建一个SDK以获得完整的平台支持,例如,如果某些已弃用的功能已完全从10.6 SDK中消失,但您必须使用它并且动态链接不是在这些情况下总是最好的选择.同时链接早期的SDK有时会使开发变得简单,因为它会导致与早期操作系统版本不兼容,因为它会导致与早期操作系统版本不兼容,并且任何尝试使用它无论如何都会立即导致编译器或链接器错误.

最后但并非最不重要的是Apple还从Xcode4中移除了GCC 4.0支持,这可能是某些软件正确构建所必需的,Apple在使用SDK 10.4时从未允许使用GCC 4.2编译软件,尽管我几乎不相信这会导致任何问题,毕竟使用GCC 4.2和SDK 10.6构建的软件也可以在Mac OS 10.4上运行而没有任何问题,只要已正确设置部署目标并且没有使用MacOS 10.4下不可用的功能.

当然,你总是可以在Xcode4旁边并行安装Xcode3,但这意味着你必须放弃Xcode4的所有(伟大的？)新功能,并继续使用过时的Xcode3 IDE.如果您还可以在同一个IDE中管理所有旧项目,并且可以使用任何新功能,那肯定会好得多.并非所有项目都可以在可预见的将来制作10.6或英特尔.此外,我严格反对在早期实际需要之前取消对旧平台的支持.

我们可以将此功能恢复到Xcode4吗？

bash-3.2$ sudo easy_install appscript  
Password:  
Searching for appscript  
Reading http://pypi.python.org/simple/appscript/  
Reading http://appscript.sourceforge.net  
Best match: appscript 1.0.0  
Downloading http://pypi.python.org/packages/source/a/appscript/appscript-1.0.0.tar.gz#md5=6619b637037ea0f391f45870c13ae38a  
Processing appscript-1.0.0.tar.gz  
Running appscript-1.0.0/setup.py -q bdist_egg --dist-dir /tmp/easy_install-C4d1az/appscript-1.0.0/egg-dist-tmp-yVTHww  
/usr/libexec/gcc/powerpc-apple-darwin10/4.2.1/as: assembler (/usr/bin/../libexec/gcc/darwin/ppc/as or /usr/bin/../local/libexec/gcc/darwin/ppc/as) for architecture ppc not installed  
Installed assemblers are:  
/usr/bin/../libexec/gcc/darwin/x86_64/as for architecture x86_64  
/usr/bin/../libexec/gcc/darwin/i386/as for architecture i386  

我是一个相当大的菜鸟(我已经学会了使用python和unix一点,但我从来没有处理安装.)早些时候我收到了与gcc-4.2无关的错误,我发现了一些建议重新安装XCode的帖子.我选择4.0(糟糕的选择？)现在我明白了.我不知道该做什么.

我有一个设备树文件(.dts),我想为我的powerpc基板编译文件.

我怎样才能在我的机器上进行,这不是基于powerpc的？我可以使用我的Ubuntu系统上安装的DTC吗？或者更像是使用单独的编译器并传递ARCH信息(比如使用工具链)？

我读过这个 什么时候应该担心对齐？但我仍然不知道我是否要担心放置新运算符返回的对齐指针 - 就像在这个例子中:

class A {
public:
   long double a;
   long long b;
   A() : a(1.3), b(1234) {}
};

char buffer[64];

int main() {
   // (buffer + 1) used intentionally to have wrong alignment
   A* a = new (buffer + 1) A(); 
   a->~A();
}

__alignof(A) == 4,(buffer + 1)是不对齐的4.但一切正常 - 这里有完整的例子:http://ideone.com/jBrk8

如果这取决于架构,那么我正在使用:linux/powerpc/g ++ 4.xx

[更新]发布此问题后,我读了这篇文章:http://virtrev.blogspot.de/2010/09/memory-alignment-theory-and-c-examples.html.也许在我的情况下唯一的缺点是性能损失,我的意思是未对齐的访问成本超过对齐？

我有一个makefile透明的Linux(x86_64)和OS X Intel(x86_64).这使用64位特定GCC选项.

有没有办法调整makefile,以便我可以构建32位和64位OS X PPC(ppc,ppc64),而无需维护单独的,特定于arch的makefile - 可能类似于预处理器指令,可以确定建筑前的建筑？

Xcode4放弃了PPC支持,所以当我尝试构建PIL时,它会引发仇恨:

Bens-MacBook-Air:Imaging-1.1.7 bkeating$ python setup.py build
running buildrunning build_pyrunning build_ext
--- using frameworks at /System/Library/Frameworks
building '_imaging' extension
/usr/bin/gcc-4.0 -fno-strict-aliasing -fno-common -dynamic -DNDEBUG -g -fwrapv -Os -Wall -Wstrict-prototypes -DENABLE_DTRACE -arch i386 -arch ppc -arch x86_64 -pipe -DHAVE_LIBJPEG -DHAVE_LIBZ -I/System/Library/Frameworks/Tcl.framework/Headers -I/System/Library/Frameworks/Tk.framework/Headers -I/usr/local/include/freetype2 -IlibImaging -I/System/Library/Frameworks/Python.framework/Versions/2.6/include -I/usr/local/include -I/usr/include -I/System/Library/Frameworks/Python.framework/Versions/2.6/include/python2.6 -c decode.c -o build/temp.macosx-10.6-universal-2.6/decode.o
/usr/libexec/gcc/powerpc-apple-darwin10/4.2.1/as: assembler (/usr/bin/../libexec/gcc/darwin/ppc/as or /usr/bin/../local/libexec/gcc/darwin/ppc/as) for architecture ppc not installed
Installed assemblers are:
/usr/bin/../libexec/gcc/darwin/x86_64/as for architecture x86_64
/usr/bin/../libexec/gcc/darwin/i386/as for architecture i386
decode.c:688: fatal error: error writing to -: Broken pipe …

我们的项目(C++,Linux,gcc,PowerPC)由几个共享库组成.在发布新版本的软件包时,只应更改那些源代码实际受影响的库."改变"是指绝对二进制身份(比较文件的校验和.不同的校验和 - >根据策略的不同版本).(我应该提到整个项目总是立即构建,无论是否有任何代码更改每个库).

通常,这可以通过隐藏包含的Header文件的私有部分而不是更改公共文件来实现.

但是,有一种情况只是delete添加到库libTableManager.so的类TableManager(在TableManager.cpp文件中!)的析构函数中,还有库libB.so的二进制/校验和(它使用类TableManager)已经改变了.

TableManager.h:

class TableManager 
{
public:
    TableManager();
    ~TableManager();
private:
    int* myPtr;
}

TableManager.cpp:

TableManager::~TableManager()
{
    doSomeCleanup();
    delete myPtr;     // this delete has been added
}

通过查看libB.so readelf --all libB.so,查看.dynsym部分,结果发现所有函数的长度,甚至是其他库中动态使用的函数的长度都存储在libB中!它看起来像这样(长度是第3列中的668):

527: 00000000 668 FUNC GLOBAL DEFAULT UND _ZN12TableManagerD1Ev

所以我的问题是:

1. 为什么函数的长度实际存储在客户端lib中？起始地址不足够吗？
2. 在编译/链接libB.so(某种"剥离")时,这可以以某种方式被抑制吗？我们真的希望减少这种依赖程度......

为了在PowerPC上寻找一个好的内存策略,我写了几个复制函数.使用具有高速缓存提示(dcb*)的Altivec或fp寄存器可以使大数据的简单字节复制循环的性能提高一倍.最初很满意的是,我定期记忆,看看它的比较...比我最好的速度快10倍!我无意重写memcpy,但我希望从中学习并加速几个简单的图像过滤器,这些过滤器花费大部分时间将像素移入和移出内存.

Shark分析显示它们的内部循环使用dcbt预取,有4个向量读取,然后是4个向量写入.在调整了我的最佳函数以便每次迭代运行64个字节之后,memcpy的性能优势仍然令人尴尬.我正在使用dcbz来释放带宽,Apple没有使用任何东西,但两个代码都倾向于对商店犹豫不决.

prefetch
  dcbt future
  dcbt distant future
load stuff
  lvx image
  lvx image + 16
  lvx image + 32
  lvx image + 48
  image += 64
prepare to store
  dcbz filtered
  dcbz filtered + 32
store stuff
  stvxl filtered
  stvxl filtered + 16
  stvxl filtered + 32
  stvxl filtered + 48
  filtered += 64
repeat

有没有人对为什么非常相似的代码有如此戏剧性的性能差距有一些想法？我喜欢用真正的图像过滤器来腌制真正的图像过滤器!

附加信息:所有数据都是矢量对齐的.我正在制作图像的过滤副本,而不是替换原始图像.该代码在PowerPC G4,G5和Cell PPU上运行.Cell SPU版本已经非常快.

我有一个Lion(10.7.1)系统,我在其上安装了Xcode 4.2.假设我有一个简单的C程序helloWorld.c如下:

#include <stdio.h>
main() {
  printf("hello, world\n");
}

使用此设置,我想尝试编译helloWorld.c以在PPC和PPC64体系结构上使用,例如:

$ gcc -arch ppc helloWorld.c -o helloWorld

这给出以下错误消息:

llvm-gcc-4.2: error trying to exec '/usr/bin/../llvm-gcc-4.2/bin/powerpc-apple-darwin11-llvm-gcc-4.2': execvp: No such file or directory

如何将PowerPC的支持恢复到我的Xcode 4安装？

我已经尝试过此前Stack Overflow帖子中列出的说明,但这些说明不适用于我的Lion安装.

我正在使用Apple的开发站点上的Xcode 3.2.6安装程序.

从符号链接,我怀疑这些指令适用于10.6安装,但不适用于10.7.

在任何情况下,Xcode 3.2.6安装中的某些源文件和目录不存在,无法从Xcode 3安装中的其他位置创建符号链接.(例如,没有/Xcode3/usr/bin用于链接as二进制文件的目录.)

有没有人幸运从Lion系统编译PPC和PPC64二进制文件？

要获得赏金,请写一个相当详细的答案.对于我自己,也为后人.:)

编辑 - 2011年8月31日

所以我尝试了Laurent指出并进一步改进的修改,但这还不足以让PPC支持工作.

我添加了符号链接,试图帮助gcc找到所需的资源:

$ sudo ln -s /Xcode3/usr/llvm-gcc-4.2/bin/powerpc-apple-darwin10-llvm-gcc-4.2 /usr/llvm-gcc-4.2/bin/powerpc-apple-darwin10-llvm-gcc-4.2 
$ sudo ln -s /Xcode3/usr/llvm-gcc-4.2/bin/powerpc-apple-darwin10-llvm-g++-4.2 /usr/llvm-gcc-4.2/bin/powerpc-apple-darwin10-llvm-g++-4.2
$ sudo ln …

PowerPC分支只有24位可用于目标偏移,因此如果文本部分太大,则一端的分支将无法到达另一端的目标.有一个更长的指令序列可以到达更远的目标(偏移量是32位而不是24位),但GCC默认不使用它,除非你通过它-mlongcall选项.但是,即使启用此选项,GCC仍会为某些功能生成短调,即operator new和operator delete

例如,给定此代码:

extern void foo();

int main(int argc, char** argv) {
    foo();
    new char;
}

正常运行的GCC将生成程序集:

bl _Z3foov // void foo()
bl _Znwj   // operator new(unsigned int)

使用该-mlongcall选项运行GCC会生成:

lis r9, _Z3foov@ha
addi r9, r9, _Z3foov@l
mtctr r9
bctrl
bl _Znwj

foo()正如预期的那样,前四个指令是一个长期调用,但调用operator new没有改变.对随机libc和libstdc ++函数的调用都按预期转换为长调用.为什么operator new和operator delete电话仍然最终作为bl指示？有没有办法迫使海湾合作委员会长期打电话？我在64位PowerPC Fedora机器上使用GCC 4.7.2(虽然我正在构建32位)