Re: Patch: Support for picoJava

[Jeffrey A Law <law at cygnus dot com>]

  In message <199910281718.KAA03715@dilithium.transmeta.com>you write:
  > No.  The picoJava opstack isn't as painful to use as the stack in an
  > 8087.  The port generates code for a machine with 32 general
  > registers, and the register numbers are turned into stack references
  > on the way out.  But it's legal to have most operators as a source in
  > a pj_source_operand, so combine cleans things up:
So, if this is all handled "on the way out" why define STACK_REGS.  I believe
that definition controls the use of the 8087 reg-stack.c conversion code.

  > > Please use prologue/epilogue expanders if possible instead of directly
  > > generating assembly code.  Direct generation of assembly code is highly
  > > frowned upon for new ports.
  > > 
  > 
  > OK, I'll do this.  May I ask why is it frowned upon ?  Scheduling
  > picoJava code is pretty pointless, it will nearly always go into a jit
  > of some sort.
It's general direction we want to go, primarily because it's cleaner and easier
for developers to understand -- most developers understand RTL.  Few understand
all the assembly languages that ports emit.  ie it is often easier for us to
debug problems by reading RTL rather than trying to make sense out of a
particular port's assembly code.

Representing the insns as RTL also makes generation/assembly output of 
prologues
easier in the long term -- just look at the mess in the m68k port.  Much of
that hair could be avoided by generating RTL and allowing the existing patterns
to select the best way to "add X to the stack pointer" and similar concept.
Instead we have to repeat the logic in multiple locations.

It is also likely certain optimizations in the future will only be enabled for
ports that do rtl prologues/epilogues.  For example tail call elimination and
shrink wrapping.


jeff