llvm dev - May 2010 - [LLVMdev] Using LLVM to compile Objective-C on an Xbox 360

Implementing the backend (or editing the current PPC backend as needed) is a
definite option.  This seems to be the real question... which is easier...
maintaining the PPC backend or maintaining the rewriter.  Currently (in
admittedly trivial tests) I have gotten the rewriter to work and output C code. 
There are some outstanding issues to do with linking and accessing the
reflection information objective-c provides (and the rewriter properly outputs)
but I am sure the person/people who wrote the rewriter can answer those fairly
simply (or else the rewriter would be fairly useless).

As far as the runtime goes there is an implementation for windows, linux and
most likely the PS3 (since it is already a linux derivative using GCC as
mentioned).  If we have to create a runtime for PS3 and XBox that seems trivial
as the functions are very basic in nature.

My comments on OpenStep were more meant to point to the fact that we would write
our own library; really just throwing all notion of OpenStep away.  Instead of
NSObject we would create our own base DObject or something along with a DString,
DAarry, DSet, DMap, etc.  Truthfully this would be our plan anyway because we
want to follow the lead of OSX and provide these objects "toll free
bridged"... meaning we would implement them using a std c++ library object
(e.g. std::basic_string or std::vector) as the first member of the object which
will allow us to cast a DString to std::string or DArray to std::vector without
any manual or automatic marshaling. As mentioned this is how OSX implements its
NS classes, by using the equivalent CF version which again allows casting
between the objects.

On May 26, 2010, at 6:19 PM, Dale Johannesen wrote:
> llvm can output C code, but that target has bitrotted severely over the
last few months and nobody seems to be interested in fixing it.  You may need to
do some work there.  Alternatively you could implement the PPC ABI that you
need.  There are several examples of supporting multiple ABIs on the same
hardware, x86 being the most obvious.  A lot of simple stuff will probably Just
Work with the existing PPC ABI, more complicated stuff may not.  (Only 32-bit
PPC is really maintained, though, there are probably lots of problems with
64-bit.)
> 
> Objective C in llvm, AFAIK, is only used on the MacOSX targets and only
tested there.   There are sufficient secret handshakes between the compiler and
the ObjC runtime that it is unlikely to Just Work in an untested environment. 
OpenStep has a familial relationship to MacOSX ObjC runtime, but they aren't
the same and are unlikely to still be binary compatible at this point.  You may
need to do some work there also.
> 
> Summary, you can probably get this approach to work, but it's not as
easy as you're hoping.
> 
> On May 26, 2010, at 5:20 PMPDT, kdubb wrote:
> 
>> We are looking at using Objective-C/C++ in a new game engine. 
Objective C's duality of being both very dynamic and very "C"
gives us exactly what we need to make the SDK and engineering of games simpler.
>> 
>> This means that we will need a way to compile it on all platforms our
games will target.  Currently the major platforms we are concerned with
include... PC, Mac, XBox 360, PS3, iPhone.  Now the PC, Mac, iPhone and PS3 are
fairly simple.  If we build our own OpenStep libraries we can simply use LLVM to
compile directly to these platforms; the PS3 although proprietary uses GCC as a
C/C++ compiler so I am assuming Objective-C can be used fairly simply.  This
leaves us with the XBox 360.
>> 
>> The 360 is a special chip (PowerPC based) with, as far as I have
researched, a special ABI (Windows derivative).  I haven't the faintest clue
of whether code from the LLVM PPC backend would even work on the 360, much less
interoperate with the system libraries. So my formulated solution has become
this: use an LLVM backend to output C code and then compile that code with using
MS's XBox 360 compiler. I believe I have read that LLVM has a C backend
already but I don't know how to select it.
>> 
>> If I can get a proof of concept showing Objective-C code running on the
360 we are off to the races.  Any help is appreciated just not sure if all the
pieces/parts exist and/or what I am missing.  So... is this feasible?  If so...
how do I get LLVM to output C code?
>> 
>> Thanks,
>> Kevin
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>

Le 27 mai 2010 à 09:15, Kevin Wooten a écrit :
> Implementing the backend (or editing the current PPC backend as needed) is
a definite option.  This seems to be the real question... which is easier...
maintaining the PPC backend or maintaining the rewriter.  Currently (in
admittedly trivial tests) I have gotten the rewriter to work and output C code. 
There are some outstanding issues to do with linking and accessing the
reflection information objective-c provides (and the rewriter properly outputs)
but I am sure the person/people who wrote the rewriter can answer those fairly
simply (or else the rewriter would be fairly useless).
> 
> As far as the runtime goes there is an implementation for windows, linux
and most likely the PS3 (since it is already a linux derivative using GCC as
mentioned).  If we have to create a runtime for PS3 and XBox that seems trivial
as the functions are very basic in nature.
> 
> My comments on OpenStep were more meant to point to the fact that we would
write our own library; really just throwing all notion of OpenStep away. 
Instead of NSObject we would create our own base DObject or something along with
a DString, DAarry, DSet, DMap, etc.  Truthfully this would be our plan anyway
because we want to follow the lead of OSX and provide these objects "toll
free bridged"... meaning we would implement them using a std c++ library
object (e.g. std::basic_string or std::vector) as the first member of the object
which will allow us to cast a DString to std::string or DArray to std::vector
without any manual or automatic marshaling. As mentioned this is how OSX
implements its NS classes, by using the equivalent CF version which again allows
casting between the objects.

This is not how the CFBridge works. Actually, the first member of an object MUST
be a pointer to its Class (the isa pointer).  If you want to be able to put
something else, you will have to rewrite the runtime to support it.

You can read this great article about the bridge here:

http://ridiculousfish.com/blog/archives/2006/09/09/bridge/#fish_made_a_mess

and an other one here:

http://www.mikeash.com/pyblog/friday-qa-2010-01-22-toll-free-bridging-internals.html

And you can also have a look at the stripped down version of the CoreFoundation
sources to get some other clues about how it works now.

http://www.opensource.apple.com/source/CF/CF-550.13/

-- Jean-Daniel
> On May 26, 2010, at 6:19 PM, Dale Johannesen wrote:
> 
>> llvm can output C code, but that target has bitrotted severely over the
last few months and nobody seems to be interested in fixing it.  You may need to
do some work there.  Alternatively you could implement the PPC ABI that you
need.  There are several examples of supporting multiple ABIs on the same
hardware, x86 being the most obvious.  A lot of simple stuff will probably Just
Work with the existing PPC ABI, more complicated stuff may not.  (Only 32-bit
PPC is really maintained, though, there are probably lots of problems with
64-bit.)
>> 
>> Objective C in llvm, AFAIK, is only used on the MacOSX targets and only
tested there.   There are sufficient secret handshakes between the compiler and
the ObjC runtime that it is unlikely to Just Work in an untested environment. 
OpenStep has a familial relationship to MacOSX ObjC runtime, but they aren't
the same and are unlikely to still be binary compatible at this point.  You may
need to do some work there also.
>> 
>> Summary, you can probably get this approach to work, but it's not
as easy as you're hoping.
>> 
>> On May 26, 2010, at 5:20 PMPDT, kdubb wrote:
>> 
>>> We are looking at using Objective-C/C++ in a new game engine. 
Objective C's duality of being both very dynamic and very "C"
gives us exactly what we need to make the SDK and engineering of games simpler.
>>> 
>>> This means that we will need a way to compile it on all platforms
our games will target.  Currently the major platforms we are concerned with
include... PC, Mac, XBox 360, PS3, iPhone.  Now the PC, Mac, iPhone and PS3 are
fairly simple.  If we build our own OpenStep libraries we can simply use LLVM to
compile directly to these platforms; the PS3 although proprietary uses GCC as a
C/C++ compiler so I am assuming Objective-C can be used fairly simply.  This
leaves us with the XBox 360.
>>> 
>>> The 360 is a special chip (PowerPC based) with, as far as I have
researched, a special ABI (Windows derivative).  I haven't the faintest clue
of whether code from the LLVM PPC backend would even work on the 360, much less
interoperate with the system libraries. So my formulated solution has become
this: use an LLVM backend to output C code and then compile that code with using
MS's XBox 360 compiler. I believe I have read that LLVM has a C backend
already but I don't know how to select it.
>>> 
>>> If I can get a proof of concept showing Objective-C code running on
the 360 we are off to the races.  Any help is appreciated just not sure if all
the pieces/parts exist and/or what I am missing.  So... is this feasible?  If
so... how do I get LLVM to output C code?
>>> 
>>> Thanks,
>>> Kevin
>>> 





-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20100527/d61d3994/attachment.html>

Thanks for the articles! There is definitely some stuff in there I hadn't
thought of; also, it quite obviously points out that it's actually not
"toll free" at all but "very low cost"!

This won't affect us too much though since we will be creating our own
objective-c classes from scratch and we are not trying to maintain backward
compatibility.  A simple solution would just be to have a method that returns
our underlying implementation object (e.g. a std::basic_string for GString)
and/or make the ivar implementation object public and let anybody access it.

On May 27, 2010, at 1:18 AM, Jean-Daniel Dupas wrote:
> 
> Le 27 mai 2010 à 09:15, Kevin Wooten a écrit :
> 
>> Implementing the backend (or editing the current PPC backend as needed)
is a definite option.  This seems to be the real question... which is easier...
maintaining the PPC backend or maintaining the rewriter.  Currently (in
admittedly trivial tests) I have gotten the rewriter to work and output C code. 
There are some outstanding issues to do with linking and accessing the
reflection information objective-c provides (and the rewriter properly outputs)
but I am sure the person/people who wrote the rewriter can answer those fairly
simply (or else the rewriter would be fairly useless).
>> 
>> As far as the runtime goes there is an implementation for windows,
linux and most likely the PS3 (since it is already a linux derivative using GCC
as mentioned).  If we have to create a runtime for PS3 and XBox that seems
trivial as the functions are very basic in nature.
>> 
>> My comments on OpenStep were more meant to point to the fact that we
would write our own library; really just throwing all notion of OpenStep away. 
Instead of NSObject we would create our own base DObject or something along with
a DString, DAarry, DSet, DMap, etc.  Truthfully this would be our plan anyway
because we want to follow the lead of OSX and provide these objects "toll
free bridged"... meaning we would implement them using a std c++ library
object (e.g. std::basic_string or std::vector) as the first member of the object
which will allow us to cast a DString to std::string or DArray to std::vector
without any manual or automatic marshaling. As mentioned this is how OSX
implements its NS classes, by using the equivalent CF version which again allows
casting between the objects.
> 
> 
> This is not how the CFBridge works. Actually, the first member of an object
MUST be a pointer to its Class (the isa pointer).  If you want to be able to put
something else, you will have to rewrite the runtime to support it.
> 
> You can read this great article about the bridge here:
> 
> http://ridiculousfish.com/blog/archives/2006/09/09/bridge/#fish_made_a_mess
> 
> and an other one here:
> 
>
http://www.mikeash.com/pyblog/friday-qa-2010-01-22-toll-free-bridging-internals.html
> 
> And you can also have a look at the stripped down version of the
CoreFoundation sources to get some other clues about how it works now.
> 
> http://www.opensource.apple.com/source/CF/CF-550.13/
> 
> -- Jean-Daniel
> 
>> On May 26, 2010, at 6:19 PM, Dale Johannesen wrote:
>> 
>>> llvm can output C code, but that target has bitrotted severely over
the last few months and nobody seems to be interested in fixing it.  You may
need to do some work there.  Alternatively you could implement the PPC ABI that
you need.  There are several examples of supporting multiple ABIs on the same
hardware, x86 being the most obvious.  A lot of simple stuff will probably Just
Work with the existing PPC ABI, more complicated stuff may not.  (Only 32-bit
PPC is really maintained, though, there are probably lots of problems with
64-bit.)
>>> 
>>> Objective C in llvm, AFAIK, is only used on the MacOSX targets and
only tested there.   There are sufficient secret handshakes between the compiler
and the ObjC runtime that it is unlikely to Just Work in an untested
environment.  OpenStep has a familial relationship to MacOSX ObjC runtime, but
they aren't the same and are unlikely to still be binary compatible at this
point.  You may need to do some work there also.
>>> 
>>> Summary, you can probably get this approach to work, but it's
not as easy as you're hoping.
>>> 
>>> On May 26, 2010, at 5:20 PMPDT, kdubb wrote:
>>> 
>>>> We are looking at using Objective-C/C++ in a new game engine. 
Objective C's duality of being both very dynamic and very "C"
gives us exactly what we need to make the SDK and engineering of games simpler.
>>>> 
>>>> This means that we will need a way to compile it on all
platforms our games will target.  Currently the major platforms we are concerned
with include... PC, Mac, XBox 360, PS3, iPhone.  Now the PC, Mac, iPhone and PS3
are fairly simple.  If we build our own OpenStep libraries we can simply use
LLVM to compile directly to these platforms; the PS3 although proprietary uses
GCC as a C/C++ compiler so I am assuming Objective-C can be used fairly simply. 
This leaves us with the XBox 360.
>>>> 
>>>> The 360 is a special chip (PowerPC based) with, as far as I
have researched, a special ABI (Windows derivative).  I haven't the faintest
clue of whether code from the LLVM PPC backend would even work on the 360, much
less interoperate with the system libraries. So my formulated solution has
become this: use an LLVM backend to output C code and then compile that code
with using MS's XBox 360 compiler. I believe I have read that LLVM has a C
backend already but I don't know how to select it.
>>>> 
>>>> If I can get a proof of concept showing Objective-C code
running on the 360 we are off to the races.  Any help is appreciated just not
sure if all the pieces/parts exist and/or what I am missing.  So... is this
feasible?  If so... how do I get LLVM to output C code?
>>>> 
>>>> Thanks,
>>>> Kevin
>>>> 
> 
> 
> 
> 
> 
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20100527/0a4da536/attachment.html>

PS3 is not "a Linux derivative." The compilers supplied by SCE for PS3
game development are highly customized and support a customized ABI  
that will take some time to adjust LLVM and Clang to support.

You'd likely also run afoul of a TRC or two, similar to the problems  
you'll face with Microsoft TCRs mentioned earlier.

Alex

On May 27, 2010, at 12:15 AM, Kevin Wooten wrote:
> Implementing the backend (or editing the current PPC backend as  
> needed) is a definite option.  This seems to be the real question...  
> which is easier... maintaining the PPC backend or maintaining the  
> rewriter.  Currently (in admittedly trivial tests) I have gotten the  
> rewriter to work and output C code.  There are some outstanding  
> issues to do with linking and accessing the reflection information  
> objective-c provides (and the rewriter properly outputs) but I am  
> sure the person/people who wrote the rewriter can answer those  
> fairly simply (or else the rewriter would be fairly useless).
>
> As far as the runtime goes there is an implementation for windows,  
> linux and most likely the PS3 (since it is already a linux  
> derivative using GCC as mentioned).  If we have to create a runtime  
> for PS3 and XBox that seems trivial as the functions are very basic  
> in nature.
>
> My comments on OpenStep were more meant to point to the fact that we  
> would write our own library; really just throwing all notion of  
> OpenStep away.  Instead of NSObject we would create our own base  
> DObject or something along with a DString, DAarry, DSet, DMap, etc.   
> Truthfully this would be our plan anyway because we want to follow  
> the lead of OSX and provide these objects "toll free bridged"...
> meaning we would implement them using a std c++ library object (e.g.  
> std::basic_string or std::vector) as the first member of the object  
> which will allow us to cast a DString to std::string or DArray to  
> std::vector without any manual or automatic marshaling. As mentioned  
> this is how OSX implements its NS classes, by using the equivalent  
> CF version which again allows casting between the objects.
>
> On May 26, 2010, at 6:19 PM, Dale Johannesen wrote:
>
>> llvm can output C code, but that target has bitrotted severely over  
>> the last few months and nobody seems to be interested in fixing  
>> it.  You may need to do some work there.  Alternatively you could  
>> implement the PPC ABI that you need.  There are several examples of  
>> supporting multiple ABIs on the same hardware, x86 being the most  
>> obvious.  A lot of simple stuff will probably Just Work with the  
>> existing PPC ABI, more complicated stuff may not.  (Only 32-bit PPC  
>> is really maintained, though, there are probably lots of problems  
>> with 64-bit.)
>>
>> Objective C in llvm, AFAIK, is only used on the MacOSX targets and  
>> only tested there.   There are sufficient secret handshakes between  
>> the compiler and the ObjC runtime that it is unlikely to Just Work  
>> in an untested environment.  OpenStep has a familial relationship  
>> to MacOSX ObjC runtime, but they aren't the same and are unlikely  
>> to still be binary compatible at this point.  You may need to do  
>> some work there also.
>>
>> Summary, you can probably get this approach to work, but it's not  
>> as easy as you're hoping.
>>
>> On May 26, 2010, at 5:20 PMPDT, kdubb wrote:
>>
>>> We are looking at using Objective-C/C++ in a new game engine.   
>>> Objective C's duality of being both very dynamic and very
"C"
>>> gives us exactly what we need to make the SDK and engineering of  
>>> games simpler.
>>>
>>> This means that we will need a way to compile it on all platforms  
>>> our games will target.  Currently the major platforms we are  
>>> concerned with include... PC, Mac, XBox 360, PS3, iPhone.  Now the
>>> PC, Mac, iPhone and PS3 are fairly simple.  If we build our own  
>>> OpenStep libraries we can simply use LLVM to compile directly to  
>>> these platforms; the PS3 although proprietary uses GCC as a C/C++  
>>> compiler so I am assuming Objective-C can be used fairly simply.   
>>> This leaves us with the XBox 360.
>>>
>>> The 360 is a special chip (PowerPC based) with, as far as I have  
>>> researched, a special ABI (Windows derivative).  I haven't the
>>> faintest clue of whether code from the LLVM PPC backend would even
>>> work on the 360, much less interoperate with the system libraries.
>>> So my formulated solution has become this: use an LLVM backend to  
>>> output C code and then compile that code with using MS's XBox
360
>>> compiler. I believe I have read that LLVM has a C backend already  
>>> but I don't know how to select it.
>>>
>>> If I can get a proof of concept showing Objective-C code running  
>>> on the 360 we are off to the races.  Any help is appreciated just  
>>> not sure if all the pieces/parts exist and/or what I am missing.   
>>> So... is this feasible?  If so... how do I get LLVM to output C  
>>> code?
>>>
>>> Thanks,
>>> Kevin
>>> _______________________________________________
>>> LLVM Developers mailing list
>>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

By linux derivative I meant that it borrows the linux GCC ABI... and it does. 
You can compile with an off the shelf GCC cross compiler and link the resultant
object files ones compiled with the PS3 provided version.   We have done it.

Also, as both an XBox 360 and PS3 developer, there seems to me to be nothing in
the TCRs/TRCs that preclude us from using a different compiler.  There are rules
about symbol inclusion and other resultant binary requirements... but as of yet
I have not found specific ones stopping us from using a compiler that works.  In
either case the LLVM rewriter solves any other these issues as we would be just
be compiling C.

On May 27, 2010, at 8:09 AM, Alex Rosenberg wrote:
> PS3 is not "a Linux derivative." The compilers supplied by SCE
for PS3 game development are highly customized and support a customized ABI that
will take some time to adjust LLVM and Clang to support.
> 
> You'd likely also run afoul of a TRC or two, similar to the problems
you'll face with Microsoft TCRs mentioned earlier.
> 
> Alex
> 
> On May 27, 2010, at 12:15 AM, Kevin Wooten wrote:
> 
>> Implementing the backend (or editing the current PPC backend as needed)
is a definite option.  This seems to be the real question... which is easier...
maintaining the PPC backend or maintaining the rewriter.  Currently (in
admittedly trivial tests) I have gotten the rewriter to work and output C code. 
There are some outstanding issues to do with linking and accessing the
reflection information objective-c provides (and the rewriter properly outputs)
but I am sure the person/people who wrote the rewriter can answer those fairly
simply (or else the rewriter would be fairly useless).
>> 
>> As far as the runtime goes there is an implementation for windows,
linux and most likely the PS3 (since it is already a linux derivative using GCC
as mentioned).  If we have to create a runtime for PS3 and XBox that seems
trivial as the functions are very basic in nature.
>> 
>> My comments on OpenStep were more meant to point to the fact that we
would write our own library; really just throwing all notion of OpenStep away. 
Instead of NSObject we would create our own base DObject or something along with
a DString, DAarry, DSet, DMap, etc.  Truthfully this would be our plan anyway
because we want to follow the lead of OSX and provide these objects "toll
free bridged"... meaning we would implement them using a std c++ library
object (e.g. std::basic_string or std::vector) as the first member of the object
which will allow us to cast a DString to std::string or DArray to std::vector
without any manual or automatic marshaling. As mentioned this is how OSX
implements its NS classes, by using the equivalent CF version which again allows
casting between the objects.
>> 
>> On May 26, 2010, at 6:19 PM, Dale Johannesen wrote:
>> 
>>> llvm can output C code, but that target has bitrotted severely over
the last few months and nobody seems to be interested in fixing it.  You may
need to do some work there.  Alternatively you could implement the PPC ABI that
you need.  There are several examples of supporting multiple ABIs on the same
hardware, x86 being the most obvious.  A lot of simple stuff will probably Just
Work with the existing PPC ABI, more complicated stuff may not.  (Only 32-bit
PPC is really maintained, though, there are probably lots of problems with
64-bit.)
>>> 
>>> Objective C in llvm, AFAIK, is only used on the MacOSX targets and
only tested there.   There are sufficient secret handshakes between the compiler
and the ObjC runtime that it is unlikely to Just Work in an untested
environment.  OpenStep has a familial relationship to MacOSX ObjC runtime, but
they aren't the same and are unlikely to still be binary compatible at this
point.  You may need to do some work there also.
>>> 
>>> Summary, you can probably get this approach to work, but it's
not as easy as you're hoping.
>>> 
>>> On May 26, 2010, at 5:20 PMPDT, kdubb wrote:
>>> 
>>>> We are looking at using Objective-C/C++ in a new game engine. 
Objective C's duality of being both very dynamic and very "C"
gives us exactly what we need to make the SDK and engineering of games simpler.
>>>> 
>>>> This means that we will need a way to compile it on all
platforms our games will target.  Currently the major platforms we are concerned
with include... PC, Mac, XBox 360, PS3, iPhone.  Now the PC, Mac, iPhone and PS3
are fairly simple.  If we build our own OpenStep libraries we can simply use
LLVM to compile directly to these platforms; the PS3 although proprietary uses
GCC as a C/C++ compiler so I am assuming Objective-C can be used fairly simply. 
This leaves us with the XBox 360.
>>>> 
>>>> The 360 is a special chip (PowerPC based) with, as far as I
have researched, a special ABI (Windows derivative).  I haven't the faintest
clue of whether code from the LLVM PPC backend would even work on the 360, much
less interoperate with the system libraries. So my formulated solution has
become this: use an LLVM backend to output C code and then compile that code
with using MS's XBox 360 compiler. I believe I have read that LLVM has a C
backend already but I don't know how to select it.
>>>> 
>>>> If I can get a proof of concept showing Objective-C code
running on the 360 we are off to the races.  Any help is appreciated just not
sure if all the pieces/parts exist and/or what I am missing.  So... is this
feasible?  If so... how do I get LLVM to output C code?
>>>> 
>>>> Thanks,
>>>> Kevin
>>>> _______________________________________________
>>>> LLVM Developers mailing list
>>>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>> 
>> 
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>

Just to be clear, nothing in the MS TCRs require that you use a certain compiler
- it does, however, require that you link with the 360-specific C runtime
libraries. That being said, I still believe that direct binary generation is not
a feasible option, and the ObjC => C route is preferred.

Kevin, hate to be asking this but do you have access to the XDK or are you just
"aiming" for it?

- Sherief


On May 27, 2010, at 11:09 AM, Alex Rosenberg wrote:
> PS3 is not "a Linux derivative." The compilers supplied by SCE
for PS3
> game development are highly customized and support a customized ABI  
> that will take some time to adjust LLVM and Clang to support.
> 
> You'd likely also run afoul of a TRC or two, similar to the problems  
> you'll face with Microsoft TCRs mentioned earlier.
> 
> Alex