I’ve got two young teenage boys and like a lot of other young teenage boys, they love video games. The computer geek in me, of course, made me wonder how the games were made. So I spent a fair amount of my hobby time a couple years ago learning a bit about the games industry and the technological challenges they face making games look great with limited resources. It was very interesting and if I was a few years (o.k., a lot of years) younger I would have considered a career change in that direction.
But I still poke my head into gaming technology once in a while, especially when I have an excuse to test the CDT on it. One thing that I ran across in my investigation into the needs of embedded developers is support for the OpenGL ES standard. This is a cut-down yet still pretty powerful version of the OpenGL standard that lies at the heart of video games like Doom 3 and the cool desktop effects you see with Mac OS X. The ES version is used on many embedded devices such as cell phones and PDAs.
PowerVR is a chunk of 3D graphics silicon IP that is included in some pretty cool System-on-a-Chip (SoC) parts, often paired with Arm processors. I think you’ll see these chips popping up in many new and exciting places. But as this happens, they’ll need content to drive their 3D power. And that means a lot of people are going to need to learn how to program to the ES standard.
Imagination Technologies where PowerVR originates came up with a great way to get more people programming for their chips, a Windows OpenGL ES emulation environment. With this environment, you can program an OpenGL ES application and run it on your Windows box instead of having to fork out a lot of money for boards that have the PowerVR core until you get serious about it.
This is great example of why more embedded developers that I run into are excited about the Windows compiler and debugger support in the CDT I am working to deliver for CDT 4.0. With this environment you get a professional quality environment for Windows to build and debug your application with the emulator and then use the same development environment to work with the code as you polish it up for the end device. I’m really looking forward to getting this capability into developers hands so they can build some cool games. For the kids, you know…
When people ask me who the CDT’s biggest competitor is, they often expect me to say things like VisualStudio or one of the many Linux IDEs (and no, Netbeans isn’t quite there yet). But the truth is that the biggest competitor to the CDT remains good ol’ vi and make (or emacs and make for the more advanced developer). We are certainly working hard to make the CDT an easier environment to adopt, but there are still the masses that can not afford the time to climb the learning curve.
But the ‘vi and make’ answer addresses edit and build. As I’ve mentioned here before, my favorite IDE feature remains visual debugging. For me, nothing beats that quick glance at the stack and then moving over to the variables view to see what all their values are. Measure that against the number of gdb commands you’d have to enter to do the same, you just can’t beat it (did I also mention that I hate typing?).
But looking around the industry, I finally figured out who our main competitor on the debug side is, good ol’ printf. Now in some environments where it’s hard to set up a debugger and all you got is console output, you have no choice. But how do these guys live with the edit/build/debug cycle every time they want to see a different variable output? And we’ve all done it at some point in our careers and likely very recently too. We need to make sure we have the right tools to put a stop to this.
At the very least, for the embedded developer, you have JTAG to drive things at the lowest level. And with many of the JTAG devices now supporting the GDB remote protocol, you can use gdb to debug at these levels. The next step is to see the CDT better support GDB running in that configuration. And that’s what I’m working on today (sorry Windows debugger, you’ll have to wait a couple of weeks).
Tools have an immense opportunity to improve developer productivity. But in order for the developer to benefit from this, the tools need to be easy to learn and use. I think that’ll be the next big challenge for the CDT, and one we’ll need to address to be truly ‘Uber’.
Way back in February, I wrote about a really cool hardware description language called SystemC. It is essentially a C++ library that allows a programmer to model hardware concepts and included a run-time that simulates the hardware. This is one of the reasons I love C++, you can use templates and overloads and inlines to bring the abstraction layer up a few notches, essentially defining a new language, without having to build a new compiler. And it usually optimizes out to something very fast.
I’ve also been following the development of qemu, a processor emulator that runs on multiple targets and has extensibility to add emulation of peripherals as well. And, if you have a fast machine, you can almost get the same performance as the real hardware. The best thing I see about qemu is that it really lowers the barrier of entry for people who want to try out embedded development without having to spend real money on real hardware. And it is much easier to carry around to trade shows :).
Well, if you have two very cool simulation/emulation environments, wouldn’t it make sense to combine them? Of course, and that’s what a group from the Universitat Autonoma de Barcelona have done. They have implemented a bridge that appears on the qemu PCI bus for drivers to access and passes signals back and forth to the SystemC design. It’s a great idea and really opens the door wider for hardware/software co-design.
I got a new laptop last week after mentioning to my boss that I need to see what those Intel guys are up to with the multi-core support they are adding to the CDT. They already have parallel build for the managed build’s internal builder and were discussing parallizing the CDT indexers. (Not to mention I always like to have the latest gadgets, shhh). And my boss obliged.
I was a bit concerned with getting the new laptop since our new standard is for a 15″ 1680×1050 wide screen. I don’t have the best eyes in the world and the fonts looked pretty small on it. But, hey, it would be cool for watching wide screen movies at home. And after setting things up, I got the fonts looking good enough.
But after setting up my Outlook to pane things vertically and firing up Eclipse on it , I can’t believe we haven’t been using this format before. What a difference! With Eclipse, I’m always dragging the splitters left or right to reveal the outline view or the navigator views or ^M’ing and sending the Editor full screen so I can see long lines of code. Not any more. I used to use my external 19″ LCD for most of my Eclipse work, but now I’m finding enjoying working in either (the 19″ is at eye height and has bigger pixels so I can see them better, though).
So my favorite tool of the week is now wide screen LCD monitors! Although qemu is still right up there, and they are now working on adding OpenGL support, more on that when I find out more…
Oh, and, BTW, Blogger has a new editor for creating blog entries. I love what it just did for spell checking.
We’ve all been waiting to see what Sun will really do when it talks about open sourcing Java. I noticed there was a lot of mistrust amongst the open source communities, but I have no prejudices against Sun so I kept an open mind.
Today (well actually over the weekend some time), Sun officially turned on the pipes and you can download it. You can see it all at java.net. There you will find their implementations for J2ME and J2SE as well as J2EE which they had open sourced earlier. For J2SE, they only have the VM and compiler open sourced. I guess they are still working on 3rd party licensing issues to get the complete JDK contributed.
They have chosen GPL as the license with the classpath exception on the libraries so that you can link commercial code without being affected by the GPL license. I’m always a bit cautious about GPL and you really got to be careful when using it but I think it’s a pretty good choice that will help avoid the forking that Sun has worried about and enable the JDK to be shipped as part of Linux distributions, which has been a pain in the you know where in the past.
Time will tell, however, how well Sun can build the community around it. If they begin to allow committers from outside of Sun, I think you’ll see over time the mistrust fade. But if it becomes apparent that they aren’t that serious about letting others play in the sandbox they’ve made, then it will all be for naught. But if it is successful, it’ll be interesting to see how the Apache Harmony project is impacted since they are essentially duplicating effort but with a different license. We’ll need a magic decoder ring to figure this all out…
So being the hacker that I am, I drove directly into the source tree to see what the code looked like. They are using subversion, which I really hope that we at Eclipse.org will switch to one day. I also see that the VM code is written in C++ and looks pretty clean. Which, of course, brings up the question on whether you can use the CDT to work on it. Of course you can! And I’ll have to spend some time in the upcoming weeks putting a tutorial together to show how.
Interesting times ahead, of that there is no doubt.
Here we go having a debate again on Planet Eclipse. I apologize to my readers who don’t follow the Planet. But then you should. It’s always great reading!
As a member the EclipseCon 2007 program committee, I had to take offense to Wassim’s remarks about the “Contraversial” EclipseCon 2007. Now he has all rights to state his opinion and we should all respect it and take a good look at what’s going on. If he’s right, then it is something we need to take a look at and make sure it is corrected.
But I think his statements are a bit off the mark. Bjorn had a nice post that summed up a lot of how I felt about it and agree 100% with what he said there. I’d like to add a bit more from the C/C++ track perspective.
First of all, I submitted a proposal for a short tutorial to the C/C++ track that I supposedly control. I did so because, at the time, I didn’t have any proposals and was afraid that the C/C++ community was going to miss out on the opportunity. After doing a little recruiting I was able to convince a few members of the community to put in much better proposals than mine and I plan on rejecting mine in favour of theirs.
Now, if I do run into the situation that I have too few proposals for the tracks that have been allocated, or they are too weak, I will propose to offer them up to the rest of the Eclipse community to make sure we get good quality content. My understanding from the other committee members is that they plan on doing the same.
You can’t get much more open than actually showing the allocations that have been given to the various tracks. I was pleasantly surprised to see that we were being that open. I’ve never seen it before, and it does open us up for criticism so early in the process.
I guess what hasn’t been made public is that these numbers aren’t necessarily written in stone and that we already have mucked around a bit with them. And we have left the door open to do more of the same. As Bjorn mentioned, we are all focused on making the EclipseCon program the best it can be for the attendees, which will go a long way towards growing our community. And I think it’s a great thing to be doing it in the open for others to comment on and help improve.
I’ve been busy working on the CDT integration with the Windows SDK and, at the moment the Windows debug engine, to support C++ development using this SDK as a choice over cygwin/mingw for Windows development. As I’ve mentioned previously, I’m keen on getting Eclipse and the CDT in a state where it can be useful for Windows developers and open up a whole new community to this great thing we’ve got going with Eclipse.
Taking a break from debugging the debugger yesterday, I tripped over a Slashdot article that said there was going to be a press conference webcast at 5 p.m. EST announcing a partnership between Microsoft and Novell on Linux. After checking the calendar to mare sure it wasn’t April 1, I tuned in. Watching the proceedings, I got that feeling I was watching history, like when Wayne Gretzky announced his retirement. Time will tell whether Microsoft entering the Linux/open source world will change anything, but today, it looks pretty significant.
What was clear was that it is more like Microsoft grudgingly admitting Linux is important with its customers, than Microsoft throwing in the towel. But I think that is an important admission that will change how the open source world views Microsoft and, more importantly, how the Microsoft world views open source and Linux in particular.
Which brings me back to my Windows SDK integration. One of the visions we had for the CDT in the early days, was for the CDT to be the cross platform development environment that eases the transition for Windows developers who want to start working on Linux apps. It was great in theory, but the demand didn’t really materialize (and neither did the community). Time will tell whether this announcement changes that. But in the meantime, it has given me a little extra energy to try and make sure the Windows SDK integration happens for both C++ and C# (Mono may have been given a boost with this also) to at least make the path easier to follow.