Current Status

Jon Olson olson@mmsi.com
Wed Feb 17 19:20:00 GMT 1999


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


More information about the Java mailing list