 So, I'm Michael Hope, said we'll be talking about GCC, I'm Leonardo, I've tried to keep this up at a system kind of level, better? Tried to keep this up at a system kind of level instead of talking about GCC or compiler in turn or themselves, so yeah, we'll get into it. I'm not going to speak about Leonardo that much, we're a not-for-profit company, relatively recent. We use the word here, Linux, to mean everything that's involved, not just the kernel, but everything that you get in a typical open source operating system. So that's everything from the kernel through tool chain, through graphics libraries, multimedia libraries and everything else. What we want is for the Cortex-A series to be as competitive as possible. The group itself is about nine months old, we're only nine months old, but we're fairly big, there's about 90 people involved. And the next six months is where we're going to be doing a large part of the work. The initial six months were all about setting the organization up, but now we have to get into things and do things. If you're interested in more about Leonardo or how we do things, where the resources are coming from, then have a talk to me later. So in terms of the companies that are involved, there's ARM, there's the big silicon vendors like FreeScale, Samsung, ST Ericsson and TI. IBM's are in there as well, and that's quite interesting from my point of view because in the tool chain side, we're getting a lot of the people who had PowerPC experience and have looked at similar problems and are now joining us on the ARM side to help solve those same problems there. If you look at how Leonardo works, you'll see a lot of familiarity with how Ubuntu works with the six-month releases, how we do the planning, how we host things, how we run things, and that's because the organization was kicked off using some of Canonical's engineering talent and also CodeSorcery's GCC experience. And we are all about the engineering. We're not a consortium, we're not a foundation. We are very much an engineering organization. Most of those 90 people are engineers doing actual code, actual improvements. And if you want to know more about it, there's quite a good Wiki. The top-level site, the Leonardo.org site, is more on the company side of things, but if you want the nitty-gritty or how to find us, have a look on wiki.lanaro.org. This is my last slide on Leonardo, but we're all about what's next. Traditionally, you'll have good support from technology that was out a year or two ago. We're all about what's next. So there's the Cortex-A9, there's the Neon Vectorizer, and there's the SMP, especially the dual core and the quad tours that you're starting to get these days. So all of this is to make sure that if you buy one of these new Cortex-A9 chips that are just coming to the market now, you can have a good set of tools that mean you can be nice and productive and generate good code for it. Out of interest, who's involved more on the embedded side of Linux as opposed to desktop or server? And how many of you are using ARM? So pretty much most of them then. Anybody using ARM in some of the more unusual situations, like there's more and more of ARM going into server or entertainment or cinema? Interesting. So in terms of people who've got here today, there's Kiko, our VP of Engineering. He's got a presentation to do later in the day as well. And this is myself, and I'm the toolchain technical lead. My team is about 12 people. We're all around the world. I've got everybody from China through New Zealand. Very little in the US actually, and quite a bit over in Europe. There's a good list of everybody who's involved with Leno across all of the different groups up on the working under engineering team. If you're looking for some familiar faces, if you're wondering where particular people ended up, have a look on there and you might find somebody you've seen before. So why is a good question? Why are we doing this? We want to have a better ARM toolchain. There's been a recognition that GCC on ARM has been good enough, but it's lagged behind in terms of performance or lagged behind in terms of features. ARM themselves decided about a year ago to get into this area to bring GCC up to the level of the commercially available compilers, and the members that founded Leno decided on the same thing at the same time. There's a good division there. ARM's working on everything that's coming up, like the Cortex A15, which should be an interesting chip, and also on the things that being a intellectual property company, they feel they can't share like pipeline descriptions or particular micro architecture features. So on the larger side, we work on everything that has been published, so making the best use of Thumb 2, making the best use of Vectorizer, making the best use of all those features that are out in the open. And saying out the open is also how we do things, sometimes to an excessive level. So I've got more details further on, but we try and keep everything that we can in the open. There's got to be a very good reason for doing anything privately. So all of our meetings are on a public call, they're all minuted, recorded, welcome to get a hold of us on ISE or emailing lists, and I think that's better than how things have been done on ARM in the past. And also, we want to make the work available now. GCC is interesting, depending on when you do your change, the very worst cases, it could be 18 months before your change is available in a released form. So we do a couple of things about that involving consolidation, branches and backporting things to stable versions, which I'll go into in a bit. Now, part of the reason for doing this presentation is we're a fairly new group and I'd love feedback in terms of how we can be perhaps more open, perhaps ways that have worked for you before, tools and technologies, particular things that you're looking for that you think perhaps ARM has not had compared to other architectures such as Intel or PowerPC. So I'll be asking a few questions through the way and please do feel free to ask me questions as well. So what we're trying to do is, goals are all very well and good, but when push comes to shove, what you emphasize is I think what matters. So I don't want to be on balance the best choice. I want our tool chain to be the best on performance. Now, obviously, you can't just go straight for performance and ignore correctness. So we'll be best on performance and neutral on correctness. And this is really only for the Cortex-A series. We will be monitoring all of the other things that you often use it for. So we'll be monitoring the size of executables. We'll be monitoring if you optimize the size earlier ARM architectures, other architectures like x86 and x86 64. We can't let any of those regress significantly, but all things being equal, it's all about the performance. I should say there as well we do to get better testing, to get better coverage of the middle end and some of the common features. What we're putting out, we do support on ARM x86 and x86 64. So I'd be interested to know if any people here have, say, distribution experience, if having one tool chain that can work on a few different architectures is an advantage. And it sounds a little bit arrogant, but I think it's a good goal. We'd like to be the tool chain for ARM. So when people think about ARM, this is the tool chain that they pick up. So if you're running an ARM-based distribution, hopefully everything inside there has been compiled with Philanero GCC. If you're looking at a new, not so much deeply embedded product, but one where the Linux kernel has evolved, again, hopefully we'll be using our tool chain. And it's really been surprising so far, just the number of places that it's popped up. Even though we haven't been promoting it that much, it's available as an option inside Open Embedded, inside Yocto, inside Open Bricks. And with luck, it should be the default compiler in Mego and, sorry, another one's fallen off the top of my head at the moment. And we're already in use for Ubuntu, which is great. It's a mixture. At the moment, it's mainly ARM and code sorcery. So ARM themselves are doing a lot of the future work and also a lot of the maintenance work. And code sorcery is through various contracts I've been doing, adding new features, improving performance and so on. So it's a little bit light in terms of the people involved. The more information you have about the chip, the better you can do. It's not so much of a problem on the compiler because the compiler has a pipeline description inside it and does optimization around that. But I have a guy who's working on faster string routines, so as fast as you can get, mem copy, mem set, Sterly, and all that type of stuff. He's been asking for a few things that aren't