Compilers are essential in getting the optimal performance out of RISC hardware, both the current PA-RISC as well as IA-64’s EPIC architecture. But what good will the new hardware do you if the computer language you create and maintain in won’t make an improvement as well? If you write software for the HP 3000, caring about compilers and their future is elementary.

Although the newest technology for HP 3000s is more than a year away, and 3000 IA-64 systems at least two years beyond that, it’s not too early to be thinking about the future of HP 3000 compilers. All of HP’s engineering to create new hardware, without new compiler technology to match, will make up only half of the work needed to get IA-64 to the customer base and ensure a lengthy growth path for HP 3000s. That’s what made us wonder about HP’s plans for the programming languages, and how they’re being updated and re-architected for the next generation of HP 3000s.

It’s still early in the IA-64 game, but just the assurance of program compatibility won’t be enough to justify buying the new systems. Programs will have to run significantly faster, and that demands revised compilers. HP promised 3000 customers this spring that it was putting COBOL at the top of its priority list as a long lead-time project, but no notice has been given about other languages. HP’s C compiler on the 3000 needs an update just to take full advantage of the PA-8000 series introduced in the Series 979s, for example. And no supported C++ compiler is available today for the 3000.

Languages are created in HP at its Computer Language Labs, while compiler maintenance and enhancements go on in the Software Services Group (SSG). Meanwhile, the HP 3000 division (CSY) has established direct management links with SSG in the past year. And the division has hired a new translator language architect from outside CSY — working with SSG and the 3000 operating system team to develop a compiler road map.

We checked on the status of that road map, one intended to complement the hardware road map HP has released this year for HP 3000s. HP has turned over its 3000 language strategies to a pair of managers who job-share, Pam Bennett and Becky McBride. The two managers clocked in on the same day to help us track the future of MPE/iX compilers, software as essential to the HP 3000 as power cords and IMAGE databases.

Do you share the view that compilers are critical to any HP 3000 RISC-based success?

McBride: There’s so much behind-the-scenes work that has to take place to build the foundation where we can deliver the next platforms. The compilers need to be optimized to get the most out of the hardware.

Bennett: We have talked about all the building blocks for the platforms, things we need to improve in the core operating system, and we see there’s the same kind of work in the building blocks for the compilers to move us toward IA-64. There are some very key, long lead-time items that we need to start very early. The compilers and the translator are keys. Everything else we do after that hinges on these core areas like compilers.

Will customers need to recompile their applications no matter what to take full advantage of the new systems’ greater performance?

McBride: It’s similar to our migration from Classic 3000s to the Spectrum systems [in the 1980s]. We continue to be committed to compatibility and making sure the applications you developed 20 years ago will still run on IA-64. But there are steps the customer will want to go through if they want optimal performance.

Bennett: They will be getting performance boosts from the raw performance of the hardware.

So even if they don’t do a recompile, they can see better performance for their programs on the new hardware?

Bennett: Definitely. It depends on how your application is built. We’ve done some testing and discovered that some of the things we thought would provide better performance did not.

McBride: If you look at our roadmap you’ll see there’s a long period of time where IA-64 and PA-RISC co-exist. We’ll need to be working closely with our customers to assess when the right time is for them to jump to IA-64.

Will there be IA-64 compilers available for the 3000 as soon as hardware is available?

McBride: At this point, that is our objective.

Bennett: There is potentially a difference between when we could provide functional compilers to customers, and when we’d be providing compilers we need to move the operating system over to IA-64. There may be a difference between when an [IA-64] system gets out there versus a full development environment. We’d be working very closely with the software vendors and channel partners to see what their needs are then. Our ISVs are very much part of our [IA-64] solution.

What’s the plan for Modcal, the HP version of Pascal that MPE/iX is written in. Is it being ported to IA-64 hardware? The most elementary support of this operating system root language would be runtime, right?

McBride: Modcal and Pascal are basically the same compiler; Modcal is the [3000] system programming extensions. We’re leveraging as much of the new code generation [capabilities] as possible from HP-UX, and they do not explicitly support Pascal or Modcal. So it’s a big effort for us to move in that direction. We are moving forward with creating the runtime libraries, and then figuring out how we really want to go with Modcal, and whether that’s going to be the best option for us or not.

If you’re not going with Modcal, does that mean you’ll have to rewrite part of the 3000’s operating system?

McBride: One of the things we’re doing is looking at leveraging C compilers as much as possible. C might be able to step in for some of the Modcal, but we will be generating Modcal as well.

Bennett: At this point we have not completed investigations there to know what the best answer is. We’re trying to be open to both what we need to do with the operating system, and what customers will need for the best performance for their applications and ease of transition. And those are questions that don’t lend themselves to the same answer. We have a good relationship with HP’s Languages Group. We think of the whole HP team as part of our CSY team.

What are HP’s plans for transition of languages like COBOL to IA-64 hardware?

Bennett: We recognize that COBOL is fundamental to customers and their applications, and we’re very much committed to having a solution there. We’re early on in the investigation of how we’re going to do that. We’re very much a part of the COBOL J4 committee, looking at the standard going out to 2002 and where we need to get to in order to move the compiler forward, and which compiler that would be. The whole COBOL question is one we’re in support of — making sure it’s available for IA-64.

Is some of the problem with COBOL plans that the new standard’s deadline keeps slipping?

McBride: As Pam said, it has moved out, and it looks like it won’t be approved until 2002.

So will you be providing any of the interim enhancements the COBOL users are asking for in advance of when the standard is completed? Some 3000 customers want object-oriented COBOL for the system, and it doesn’t sound like they’re ready to wait three years.

Bennett: I don’t think we have a timeline yet that we can announce for when we’ll have an object-oriented solution. We’re part of the committee that’s trying to define those standards. HP has someone there who’s an active voting member. We need our strategy in place, so this conversation won’t have a lot of concrete dates. We’re definitely committed to COBOL, but we’re early on as far as which direction we’re going. How we’re going to carry forward the HP [3000 COBOL] extensions is also getting discussed at the standards board.

We’re also working with some of our third-party partners to look at some of the other application development environment tools that we could be using that would help out programmers like our COBOL programmers.

Is there going to be a C compiler engineered for HP 3000 IA-64 systems?

McBride: We are currently working on enhancements to C. Many customers have been asking for 64-bit integer support in C, and so we’re currently working on a long-long data type, to be available for customers in the fall. That’s not only for our customers — we have internal needs for that as well. We’re doing porting.

Bennett: The C compiler has become more important to CSY because a lot of new middleware and tools we’re trying to move forward on the 3000 — for example, Apache and Samba — are all really using a C compiler.

McBride: Another effort we’re working on is Java.

So Java will be replacing the work you got from some other compilers in the past?

McBride: Right, and we’re seeing that open up a lot of possibilities to getting new applications and tools on the platform, having Java available. Our focus on the Java compiler right now is the performance.

Bennett: Middleware seems to be a parallel of open systems years ago. It’s moving into the standards area, and Java is the core to that.

Is the GNU C++ compiler going to be ported for use on IA-64?

McBride: It’s something we’re looking at, but we haven’t made that decision yet. We don’t see that it will be replacing C. We continue to have a dependency on it [in CSY labs].

Are any of the current HP 3000 compilers not scheduled to make the transition to IA-64 compatibility? Since C and COBOL and Pascal will be making the transition, what about the others, like FORTRAN and Transact?

Bennett: We’re pretty early on in that investigation in the full gamut of compilers that will be available.

McBride: You’ve hit the top ones, plus FORTRAN. There’s ones that are lower in the priority list such as RPG, Transact and Business Basic. We’re still looking at whether translation does meet the need there, versus native.

Will any of the current HP 3000 compilers get re-engineered for next year’s PA-8500 systems?

McBride: We’ll do whatever we need to do to optimize for those systems. We looked at the PA 2.0 compiler to see if it would give us any benefit, and for the most part it hasn’t. But we have taken some of that [compiler] and put it into our assembler. We’re finding other ways to get our performance.

Bennett: We’re not sure we need to re-engineer those. There are some places [those compilers] provide us with a performance boost, and we’re looking at integrating some of those boosts directly into the operating system. We are in investigation, and we don’t have answers to what we’re doing with each compiler.

McBride: There are individual compiler enhancements that may be needed for other solutions that we’re developing, to meet our 30 percent- per-year performance goals. Long-long is an example, and there are changes we’ve made for large file support.

Which compilers are now being maintained and developed inside the CSY labs? We had heard that CSY took back COBOL; are there any others?

McBride: It’s all within Randy Roten’s HP SSG team, which has a dotted-line report to Pam and myself. If you look at where we are with the compilers compared to a year ago, it’s a much stronger linkage, working with the SSG team and the Computer Language Labs. That dotted-line report from our perspective has made a world of difference.

Bennett: The relationship between Support and CSY has grown immensely in that time.