This is the mail archive of the java-discuss@sourceware.cygnus.com mailing list for the GCJ project. See the GCJ home page for more information.
| Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
|---|---|---|
| Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
On Wed, 17 Feb 1999, Brian Miller wrote:
>Jon Olson wrote:
>>
>>We produce alot of microcontrollers that use ... AMD A29K.
>
>I bet bytecode maps real well to the 29K's stack architecture.
>Does GCJ's back-end take advantage of that when targetting the 29K?
The big advantage 29Ks, with their register stack, have is being able to
efficiently allocate an arbitrary number of registers on function entry
and deallocate them on exit. The large number of registers gives GCC,
in general, a register for every pseudo it generates and eliminates all
stack slot spills. This is true whether you're compiling C, C++, Java,
or almost any other languages Lots of registers makes for good code.
The 29K is incredibly good at function calls, due to its architecture.
Unfortunately, the 29K has alot of disadvantages as well:
1) The 29K requires two stacks, one for registers and one for memory
addressable things like arrays and objects. I've found from experience
that each stack needs roughly the same size as a single stack on
other microprocessors. Hence 29K needs about twice as much stack
space.
2) The 29K has no indexed offset addressing. The effective address of
anything must first be computed in a register. You thus need lots
of registers just for computing addresses, and things that take one
instruction on RISCs like SPARC or ARM require 2 instructions on A29K.
3) Each register requires 8-bits to encode in an instruction, because you
have so many of them. This makes an incredibly non-compact instruction
set. On typical C++ code, the 29K requires about 60% more code space
than a ARM.
4) AMD has ended all development on the 29K architecture. Instead, they're
targetting low end 186-386 processors for embedded applications. A
big mistake in my humble opinion.
In compiled Java, the A29K seems to fare better than with C++, since Java has
alot of fixed space overhead with all its metadata tables and Java tends to have
alot of small methods and little in-line field access. Hence, the A29K's
efficient function call help it and I've found that A29K binaries are only about
15% larger than it's StrongARM brother.
--
Jon Olson, Modular Mining Systems
3289 E. Hemisphere Loop
Tucson, AZ 85706
INTERNET: olson@mmsi.com
PHONE: (520)746-9127
FAX: (520)889-5790