Commercial compilers on Linux = Good
on
Borland C++ For Linux
·
· Score: 3, Interesting
Quite a lot of this ground has been discussed in the story I submitted Does Linux Need Another Commercial Compiler?. That being about my company's consideration of porting VectorC {PC} to Linux. It'll just be provided with the Windows version.
The upshot of that discussion was that VectorC {PC:Linux} is sheduled for release in April this year. That being based on our 2.0 engine so with C++ compatibility (currently VectorC is C only). While there was (unsurprisingly) a load of anti closed-source rhetoric in public, we did recieve a good number of serious private enquiries from people looking for a compiler such as ours on the Linux platform. It was enough to form a view that the platform is viable for us.
Ultimately I can't see any serious argument against having development tools such as these (Borland C++ and VectorC) on Linux. While it's likely of less interest to the open source/free evangelists wanting everything for free, there's definately demand where Linux is increasingly being used as an industrial platform.
Codeplay looks forward to competing with Borland on Linux.
I'd need 3 x 120GB drives. Or 2 x 120GB drives and a 60GB drive not allowing for expansion.
That it's utterly ridiculous. While I'm sure some slashdot readers wouldn't mind running a 3 drive noisy file server 24/7, I don't treat this an an option. One 80GB drive is currently doing the job.
I also dispute 50% reduction in those lossless compression formats. They seem to be about 30-40% from what I see.
I use MP3. I've taken a look at other codecs at various times but of course the limiting factor is what will actually play them. My entire music collection lives on a server so it can be played from our room in the house with random access of course. I've got a Slimp3 in the lounge which is a godsend for the missus, even she can drive the remote and the big vacuum florescent display. That wont play anything but MP3
This is a proper music collection of nearly 1,000 CDs encoded over the space of years. I started way back when L3Enc was all there was! Since then I've reencoded it all with LAME, using something non-lossy is absolutely unpractical from a storage stand point. With the greatest of respect I have to point out that those people here talking about using non-lossy compression clearly do not have their record collections in these formats. I suggest they are using these formats as little more than convienient stashes of music rather like a few tapes you'd have in the car.
I've used MP3 portables for ages (since the Rio) and still do. My current unit only plays MP3 and nothing else. I've ordered an iPod and I don't think that plays anything but MP3 either.
My standards of MP3 compression are fairly high and in this respect LAME is an absolute godsend. It's been developed for so long and the quality at higher bitrates is certainly in excess of my ability to to differentiate from the original CDs. I'm very happy with my ability to control it's settings and the excellent results I get out of it.
Sure the MP3 license situation is a bit iffy but what do I care? All my equipment plays it and I can encode it for free. I like Ogg in theory but practicality wins out for me every time over some sort of moralistic stance on the MP3 patent issues.
If I was going to choose something obscure to start with, it probably would have been MPC. I think the design philosophy for that is superb. It's got the modern technique of MP3 without the suspect elements which make MP3 difficult to achieve transparent audio even at high bitrates. MPC is absolutely stonking if you spend the bits, IE 192-256kbps. But then again, at those bitrates MP3 is the same with only some real oddball stuff showing signs of audible artifacts.
MP3 until such time as some superior codec is playable in all my equipment and the encoding software is up to the same high standards as LAME. That's a long time away, in my opinion, if ever.
The compiler authors don't have time to make processor-specific optimizations for every single flavor of x86 architecture out there;
Some compiler authors do not. My company treats processor-specific optimizations as a core feature especially when it comes to SIMD implementations. Intel C/C++ 5.0 does some vectorization for Intel CPU features. Our compiler, VectorC, is designed to vectorize real-world media operations for all CPUs on the market today.
CPU specific binaries come out of the compiler essentially for free. One can either use libaries or seperate executables for the equipped CPU. In our view these still far too much generic compilation of performance sensitive code.
AMD's recent domination of performance to price ratio has also made some unlikely new friends. Namely that of distributed Linux-based high performance and scientific computing. Formerly Intel based platforms with the Intel compiler, now there's another option to consider - AMD based machines with our compiler. Especially when we have C++ at any rate.
Ever seen one of the full size WinCE machines? I've thought one of those would be a superb platform to run Linux on. They have MIPs, ARM or SH3/4 CPUs - full sized keyboards and 10" or so DSTN displays. They weren't very popular of course, since forking out that money for WinCE and all the crippled half-working 'Pocket' range of MS applications was a bit much for anyone to swallow.
What they WERE good for is, all solid state battery backed memory. They'd run for an entire day on batterys no problem. Hell you can slap in Compact Flash and PCMCIA cards. CF lan cards are just the ticket. Of course... drivers would be the issue.
I had a Compaq Aero 8000 for awhile (until I realised how much WinCE sucked) and this is pretty much the perfect box for this kind of thing imo.
The big drawback for the chap starting this thread is that they can't deliver the required power to many (or even most) PCMCIA devices and 802.11B may well be one of those.
P.S. I got mine being disposed of dirt cheap frin a shop on Tottenham Court Road in London. It's discontinued so they're dumping stock.
I worked on a car in the first World Solar Challenge. In fact, I was working/studying at the Northern Territory University (NTU) in Darwin Australia at the time. That's where the race starts, so you can imagine as the 'local boys', we had a good deal of support from the crowd at the starting line!
As has been pointed out elsewhere, this isn't really about making a solar powered commuting vehical. It's worth noting how much additional benefits came out of the fundamental research going into the entries in the race. A GM team built a car that stormed in to win the first race, and little wonder since they had millions of dollars to play with and bought the entire world's terrestrial supply of galium arsenide solar cells at the time (the rest being bound for space).
A lot of fundamental research was done on improving the efficiency of electric motors, their drive electronics and simulations as to the most efficient way to drive these vehicals. Hell, even the telemetry to the support vehical was something pretty new for the time!
There ought to be many more of these sort of worldwide research challenges. Especially in areas that really will become important soon such as fuel cells as others have pointed out. I see now they have difference classes in this race for battery as it is - little wonder, my god we would have died for Lithium Ion batteries in 1987!
It's just a bit of a shame that the organisation of the race itself is fairly poor and that the web sites get dumped with each new event and hence sponsor. It could have made for a wonderful web site with all that archive material.
Just as well NTU has done a fab site of their own.
P.S. You can't imagine my elation at seeing NTU's car come second in the 2000 race, not to mention claiming the world record for fastest long distance solar car!
Sure when you see these videophone interviews on the news channels, you can argue we have better technology today and ought to be using it. That's undoubtedly true but it does make me think back to not so long ago when this sort of stuff would have seemed like sci-fi.
I remember when I was at Uni in remote far Northern Australia. I worked in a facility there which did a lot of video production and so on. The Uni operated a commercial video conferencing center, charging hundreds of dollars an hour. It did brisk trade because the alternative was flying the length of Australia which took a day and a whole hell of a lot more cash!
The box that did the codec work was HUGE. It had boards loaded with 68k series CPUs. We mounted a professional camera on a big custom-made roller stand with a huge TV in it. 2 *megabits* of bandwidth got you video quality which I put roughly at what we're seeing on these newscaster videos today. Of course you had to phone up the telco and get them to route through 2 megabits of data stream to the other side of the country at the time.
Now you can do this stuff anywhere on the planet via a satellite phone, probably for cheaper than we did it back then. That's pretty amazing really and looking at things in perspective like that, you start to realise that practical consumer video-capable mobile phone really will turn up one day. Not for 3G, but one day.
I sure would like to call up the Old Man and speak to him face to face, even though he's the other side of the world. It's gonna happen soon and that's something to be impressed with in my opinion.
I was more interested in how you came to that conclusion really. In fact VectorC is less portable than GCC, or at least it takes more work to port to a particular CPU. The reason is that the optimizer stage, after the high level intermediary representation, needs to know something about the capabilities of the CPU. Especially with regards to vector units and so on.
That's the strength of VectorC in some ways, the back end code generator feeds back the capabilities of the CPU to higher up in the compiler pipeline. So it's more work porting to a new CPU than it is, say, GCC which just bolts on a new code generator after the level-level intermediary representation.
The Playstation 2 is an extreme example. You have a MIPS CPU with a custom built in vector unit via the MMI instructions. Let alone potentially driving one vector unit in macro mode and auto-vectorizing for that. Naturally GCC doesn't do any of that on PS2 and in fact it's pretty damn poor when it comes to know about what's fast and what's slow to do on MIPS as well.
VectorC on PS2 is written quite specifically for that platform, so it's most certainly harder to port. Then again it wouldn't be worth porting unless we were doing all these things.
I could turn your argument in the other side, and explain that there is something wrtong with vectorC, because its internal structure make it difficult to port to a new platform.
As for my back end, the PowerPC, I would be very surprised if any other compilers produced optimized code at CodeWarriors level.
On the PPC can you vectorize a real-world function that adds two textures together with saturation? If you can do that, it'll be my turn to be very surprised:)
I'm sure there is a market on the Mac, but just not a very big one. We wouldn't want to bet on it and splash out a lot of development time when there's several 'no brainer' platforms to do yet.
He also didn't think your symbol information would be compatible with VTune or the other standard Windows profilers
That is not correct, you can use VTune just fine. That's exactly how we see people using VectorC today. Your points on conformance testing are well taken. That is being done with the C++ version and obviously well announce results when we release that compiler.
... the compiler choked on some valid code...
Quite possible you ran into a 1.0 bug. There's a dramatic difference with the recent 1.2 release. VectorC can now compile entire games and middleware engines and demonstrate a boost in performance in many cases. That's not something I would have said at the beginning of this year.
So far as I can see, I'm supposed to dump my compiler for something that lets me use half a dozen instructions I can get with inline assembly or Intel's _free_ compiler, where Windows is concerned.
Well clearly I can't agree with your viewpoint on what a proper vectorizing compiler is capable of doing. Now if you're prepared to go do all the inline assembly for the various SIMD implementations on x86 CPUs then indeed, you have no use for VectorC. However that's pretty rare for game developers working to deadlines in my experience.
Shouldn't you finish your tools and make them work on one platform before you go trying to pitch them on others?
VectorC works marvellously on Win32 and is already being used by game and middleware developers to good effect. However I like your tone, you think you could come over and whip me with an apple in my mouth?:)
> Funny, I've seen it the other way around - I suppose it's just a matter of who you work with.
Well, we've literally been calling up every game developer in the UK and it's the same story nearly every time. Of course DirectX is one of the classic requirements for C++ for a start...
The real strength, however, is CodeWarrior's optimization and code generation.
Hello Metroworks guy!
You may be able to shed light on something which I found odd. You're aware Criterion in the UK distribute Metroworks products in Europe? You may also be aware that they make the Renderware middleware engine also.
I was quite interested to learn that they don't use Metroworks to compile Renderware, despite being the distributors. They use the Intel compiler. Why is that do you think?
I'm just interested, not looking for an arguement on the merits of our respective compilers. Your compiler is lofty goal for us to aim for. We have a version of the interactive demo with Metroworks in it and we were quite surprised by how well Metroworks did in those tests versus Intel and MSVC! I must put that on our site at some point, since it's especially relevant for game dev stuff.
It's still pretty early days for us, it could well be something broken! Showing your code to our lads could either a) point out something you need to do to make things faster or b) point out something we need to fix/improve.
The only thing that makes me think something is wrong with your values is that we just don't see that sort of lackluster performance in our tests. If we did, we'd fix the compiler!
Mat 'Lurks' Bettinson, Codeplay Ltd.
Where the lame seem to think that every little request for something coming from a company is a thinly veiled ad, etc.
The office lads warned me but I still wasn't quite prepared for this:)
how much bigger/smaller is your code compared to the other compilers?
I don't know really, it's not been much of an issue - only performance. I'm not sure embedded folks have a requirement for what we do particularly well, then again I've been surprised before (the scienfific stuff).
Mat 'Lurks' Bettinson, Codeplay Ltd.
Perhaps even making the compiler and libs free to distro, but the development enviroment closed.
That's not really our philosophy. We want to provide a high performance compiler which you plug into the development environment of your choice. We're not an IDE developer, we a compiler developer.
Even if Codeplay was to use the Edison Design Group C++ front end [edg.com] -- highly likely, as it's famous throughout the industry as an extraordinarily compliant, high quality front end,...
Implementing C++ properly natively is a requirement so that we can attempt to do the sorts of things VectorC does which no other compiler does. Simply put, if we used someone else's translator - we'd have C++ capability but almost certainly would be no faster than other C++ compilers.
... and seemingly a perfect match to the existing VectorC back end -- I'm highly skeptical this schedule could be met.
I assure you, we are. The work is almost complete, what remains is the significant internal testing and bug fixing which we estimate will require the rest of the year.
We have a fridge full of Redbull, believe me we can do it.:)
Don't wait for Apple. They're not the ones to talk to.
Well, it's a bit more complex than that isn't it. Us porting to a platform involves the following kind of issues;
Is the platform easy? IE. Do we have the code generation for that platform already?
Is it a heavy games and multimedia platform?
Are the tools substandard on that platform?
If we're not doing well in the above, then we'd not consider the platform a priority. Unless, of course, someone wants to give us money to do it. That's not out of the question where it's a proprietary platform such as a games console or, to an extent, the Apple Mac.
Apple is a good target on one level because the vector unit in the G4 is the best vector unit in any consumer CPU. There's also games development and, more importantly on that platform, there's a lot of performance-sensitive multimedia application development. Apple like to crow about how good their CPU is, so one would have thought they'd like a tool on their platform to prove it.
Regarding your other suggestions,maybe down the line we'll be looking at more business orientated high performance computing but that's not why Codeplay started up. From experience we have our work cut out talking to the various corporate players coming from an unknown company with 'play' in their name and 'games' on their web site. I think to be successful there we'd have to spin-off some high performance computing company or something. And definately no chins on the web site:)
Linux is a special case. For all other platforms, we take a straight business viewpoint based on the numbers. To be frank, we've got a LOT of work/platforms on our plate as it is without finding new platforms unless they were going to pay.
The Playstation 2 tools will pay the bills. Linux would just be 'cool', so long as it didn't cost us significant money and didn't generate bad PR. That's my view at the minute.
I'm all in favour of a compiler which restricts its features to those it does well instead of providing half-baked implementations of C++'isms just to bump up the feature list.
While I think a couple of our developers would agree with you, it turns out that extensive use of C++'s features are very common in games. At least in Europe. C is a bit more common in the US for games development and the Japanese wouldn't touch C++ with someone else's bargepole.
It's been a bit of pain for us being based in the UK, everyone uses C++ here!
It's quite nice to work with id who code entirely in vanilla C.
Slashdot Mirror
The upshot of that discussion was that VectorC {PC:Linux} is sheduled for release in April this year. That being based on our 2.0 engine so with C++ compatibility (currently VectorC is C only). While there was (unsurprisingly) a load of anti closed-source rhetoric in public, we did recieve a good number of serious private enquiries from people looking for a compiler such as ours on the Linux platform. It was enough to form a view that the platform is viable for us.
Ultimately I can't see any serious argument against having development tools such as these (Borland C++ and VectorC) on Linux. While it's likely of less interest to the open source/free evangelists wanting everything for free, there's definately demand where Linux is increasingly being used as an industrial platform.
Codeplay looks forward to competing with Borland on Linux.
Mat Bettinson - Codeplay Ltd.
I forgot actually, dickhead. Christ such tossers here.
That it's utterly ridiculous. While I'm sure some slashdot readers wouldn't mind running a 3 drive noisy file server 24/7, I don't treat this an an option. One 80GB drive is currently doing the job.
I also dispute 50% reduction in those lossless compression formats. They seem to be about 30-40% from what I see.
I use MP3. I've taken a look at other codecs at various times but of course the limiting factor is what will actually play them. My entire music collection lives on a server so it can be played from our room in the house with random access of course. I've got a Slimp3 in the lounge which is a godsend for the missus, even she can drive the remote and the big vacuum florescent display. That wont play anything but MP3 This is a proper music collection of nearly 1,000 CDs encoded over the space of years. I started way back when L3Enc was all there was! Since then I've reencoded it all with LAME, using something non-lossy is absolutely unpractical from a storage stand point. With the greatest of respect I have to point out that those people here talking about using non-lossy compression clearly do not have their record collections in these formats. I suggest they are using these formats as little more than convienient stashes of music rather like a few tapes you'd have in the car. I've used MP3 portables for ages (since the Rio) and still do. My current unit only plays MP3 and nothing else. I've ordered an iPod and I don't think that plays anything but MP3 either. My standards of MP3 compression are fairly high and in this respect LAME is an absolute godsend. It's been developed for so long and the quality at higher bitrates is certainly in excess of my ability to to differentiate from the original CDs. I'm very happy with my ability to control it's settings and the excellent results I get out of it. Sure the MP3 license situation is a bit iffy but what do I care? All my equipment plays it and I can encode it for free. I like Ogg in theory but practicality wins out for me every time over some sort of moralistic stance on the MP3 patent issues. If I was going to choose something obscure to start with, it probably would have been MPC. I think the design philosophy for that is superb. It's got the modern technique of MP3 without the suspect elements which make MP3 difficult to achieve transparent audio even at high bitrates. MPC is absolutely stonking if you spend the bits, IE 192-256kbps. But then again, at those bitrates MP3 is the same with only some real oddball stuff showing signs of audible artifacts. MP3 until such time as some superior codec is playable in all my equipment and the encoding software is up to the same high standards as LAME. That's a long time away, in my opinion, if ever.
Some compiler authors do not. My company treats processor-specific optimizations as a core feature especially when it comes to SIMD implementations. Intel C/C++ 5.0 does some vectorization for Intel CPU features. Our compiler, VectorC, is designed to vectorize real-world media operations for all CPUs on the market today.
CPU specific binaries come out of the compiler essentially for free. One can either use libaries or seperate executables for the equipped CPU. In our view these still far too much generic compilation of performance sensitive code.
AMD's recent domination of performance to price ratio has also made some unlikely new friends. Namely that of distributed Linux-based high performance and scientific computing. Formerly Intel based platforms with the Intel compiler, now there's another option to consider - AMD based machines with our compiler. Especially when we have C++ at any rate.
What they WERE good for is, all solid state battery backed memory. They'd run for an entire day on batterys no problem. Hell you can slap in Compact Flash and PCMCIA cards. CF lan cards are just the ticket. Of course... drivers would be the issue.
I had a Compaq Aero 8000 for awhile (until I realised how much WinCE sucked) and this is pretty much the perfect box for this kind of thing imo.
The big drawback for the chap starting this thread is that they can't deliver the required power to many (or even most) PCMCIA devices and 802.11B may well be one of those.
P.S. I got mine being disposed of dirt cheap frin a shop on Tottenham Court Road in London. It's discontinued so they're dumping stock.
As has been pointed out elsewhere, this isn't really about making a solar powered commuting vehical. It's worth noting how much additional benefits came out of the fundamental research going into the entries in the race. A GM team built a car that stormed in to win the first race, and little wonder since they had millions of dollars to play with and bought the entire world's terrestrial supply of galium arsenide solar cells at the time (the rest being bound for space).
A lot of fundamental research was done on improving the efficiency of electric motors, their drive electronics and simulations as to the most efficient way to drive these vehicals. Hell, even the telemetry to the support vehical was something pretty new for the time!
There ought to be many more of these sort of worldwide research challenges. Especially in areas that really will become important soon such as fuel cells as others have pointed out. I see now they have difference classes in this race for battery as it is - little wonder, my god we would have died for Lithium Ion batteries in 1987!
It's just a bit of a shame that the organisation of the race itself is fairly poor and that the web sites get dumped with each new event and hence sponsor. It could have made for a wonderful web site with all that archive material.
Just as well NTU has done a fab site of their own.
P.S. You can't imagine my elation at seeing NTU's car come second in the 2000 race, not to mention claiming the world record for fastest long distance solar car!
I remember when I was at Uni in remote far Northern Australia. I worked in a facility there which did a lot of video production and so on. The Uni operated a commercial video conferencing center, charging hundreds of dollars an hour. It did brisk trade because the alternative was flying the length of Australia which took a day and a whole hell of a lot more cash!
The box that did the codec work was HUGE. It had boards loaded with 68k series CPUs. We mounted a professional camera on a big custom-made roller stand with a huge TV in it. 2 *megabits* of bandwidth got you video quality which I put roughly at what we're seeing on these newscaster videos today. Of course you had to phone up the telco and get them to route through 2 megabits of data stream to the other side of the country at the time.
Now you can do this stuff anywhere on the planet via a satellite phone, probably for cheaper than we did it back then. That's pretty amazing really and looking at things in perspective like that, you start to realise that practical consumer video-capable mobile phone really will turn up one day. Not for 3G, but one day.
I sure would like to call up the Old Man and speak to him face to face, even though he's the other side of the world. It's gonna happen soon and that's something to be impressed with in my opinion.
Actually the Standard Edition now has Athlon support, just not Pentium 4 support.
I was more interested in how you came to that conclusion really. In fact VectorC is less portable than GCC, or at least it takes more work to port to a particular CPU. The reason is that the optimizer stage, after the high level intermediary representation, needs to know something about the capabilities of the CPU. Especially with regards to vector units and so on.
That's the strength of VectorC in some ways, the back end code generator feeds back the capabilities of the CPU to higher up in the compiler pipeline. So it's more work porting to a new CPU than it is, say, GCC which just bolts on a new code generator after the level-level intermediary representation.
The Playstation 2 is an extreme example. You have a MIPS CPU with a custom built in vector unit via the MMI instructions. Let alone potentially driving one vector unit in macro mode and auto-vectorizing for that. Naturally GCC doesn't do any of that on PS2 and in fact it's pretty damn poor when it comes to know about what's fast and what's slow to do on MIPS as well.
VectorC on PS2 is written quite specifically for that platform, so it's most certainly harder to port. Then again it wouldn't be worth porting unless we were doing all these things.
:)
Mat 'Lurks' Bettinson, Codeplay Ltd.
On the PPC can you vectorize a real-world function that adds two textures together with saturation? If you can do that, it'll be my turn to be very surprised :)
I'm sure there is a market on the Mac, but just not a very big one. We wouldn't want to bet on it and splash out a lot of development time when there's several 'no brainer' platforms to do yet.
I'm sorry, I had confused your post for another that quoted some 'lackluster' figures. Oops!
That is not correct, you can use VTune just fine. That's exactly how we see people using VectorC today. Your points on conformance testing are well taken. That is being done with the C++ version and obviously well announce results when we release that compiler.
Quite possible you ran into a 1.0 bug. There's a dramatic difference with the recent 1.2 release. VectorC can now compile entire games and middleware engines and demonstrate a boost in performance in many cases. That's not something I would have said at the beginning of this year.
Well clearly I can't agree with your viewpoint on what a proper vectorizing compiler is capable of doing. Now if you're prepared to go do all the inline assembly for the various SIMD implementations on x86 CPUs then indeed, you have no use for VectorC. However that's pretty rare for game developers working to deadlines in my experience.
VectorC works marvellously on Win32 and is already being used by game and middleware developers to good effect. However I like your tone, you think you could come over and whip me with an apple in my mouth? :)
> Funny, I've seen it the other way around - I suppose it's just a matter of who you work with. Well, we've literally been calling up every game developer in the UK and it's the same story nearly every time. Of course DirectX is one of the classic requirements for C++ for a start...
Hello Metroworks guy!
You may be able to shed light on something which I found odd. You're aware Criterion in the UK distribute Metroworks products in Europe? You may also be aware that they make the Renderware middleware engine also.
I was quite interested to learn that they don't use Metroworks to compile Renderware, despite being the distributors. They use the Intel compiler. Why is that do you think?
I'm just interested, not looking for an arguement on the merits of our respective compilers. Your compiler is lofty goal for us to aim for. We have a version of the interactive demo with Metroworks in it and we were quite surprised by how well Metroworks did in those tests versus Intel and MSVC! I must put that on our site at some point, since it's especially relevant for game dev stuff.
Mat 'Lurks' Bettinson, Codeplay Ltd.
Indeed, that complicates the PPC issue. Although interestingly Metroworks are shifting towards GCC apparently.
It's still pretty early days for us, it could well be something broken! Showing your code to our lads could either a) point out something you need to do to make things faster or b) point out something we need to fix/improve. The only thing that makes me think something is wrong with your values is that we just don't see that sort of lackluster performance in our tests. If we did, we'd fix the compiler! Mat 'Lurks' Bettinson, Codeplay Ltd.
That's not really our philosophy. We want to provide a high performance compiler which you plug into the development environment of your choice. We're not an IDE developer, we a compiler developer.
Mat 'Lurks' Bettinson, Codeplay Ltd.
Implementing C++ properly natively is a requirement so that we can attempt to do the sorts of things VectorC does which no other compiler does. Simply put, if we used someone else's translator - we'd have C++ capability but almost certainly would be no faster than other C++ compilers.
I assure you, we are. The work is almost complete, what remains is the significant internal testing and bug fixing which we estimate will require the rest of the year.
We have a fridge full of Redbull, believe me we can do it. :)
Mat 'Lurks' Bettinson, Codeplay Ltd.
Well, it's a bit more complex than that isn't it. Us porting to a platform involves the following kind of issues;
If we're not doing well in the above, then we'd not consider the platform a priority. Unless, of course, someone wants to give us money to do it. That's not out of the question where it's a proprietary platform such as a games console or, to an extent, the Apple Mac.
Apple is a good target on one level because the vector unit in the G4 is the best vector unit in any consumer CPU. There's also games development and, more importantly on that platform, there's a lot of performance-sensitive multimedia application development. Apple like to crow about how good their CPU is, so one would have thought they'd like a tool on their platform to prove it.
Regarding your other suggestions,maybe down the line we'll be looking at more business orientated high performance computing but that's not why Codeplay started up. From experience we have our work cut out talking to the various corporate players coming from an unknown company with 'play' in their name and 'games' on their web site. I think to be successful there we'd have to spin-off some high performance computing company or something. And definately no chins on the web site :)
Linux is a special case. For all other platforms, we take a straight business viewpoint based on the numbers. To be frank, we've got a LOT of work/platforms on our plate as it is without finding new platforms unless they were going to pay.
The Playstation 2 tools will pay the bills. Linux would just be 'cool', so long as it didn't cost us significant money and didn't generate bad PR. That's my view at the minute.
Mat 'Lurks' Bettinson, Codeplay Ltd.
While I think a couple of our developers would agree with you, it turns out that extensive use of C++'s features are very common in games. At least in Europe. C is a bit more common in the US for games development and the Japanese wouldn't touch C++ with someone else's bargepole.
It's been a bit of pain for us being based in the UK, everyone uses C++ here!
It's quite nice to work with id who code entirely in vanilla C.
Mat 'Lurks' Bettinson, Codeplay Ltd.