RE: BCO entry code - parameter passing on RISC

> After a day of running gdb in parallel on my MacOS X and Linux [quite 
> annoying because of different keyboard layouts ;-) ], I've 
> come to the following conclusion:
> 
> The entry code for BCOs expects all parameters to be on the 
> stack, but 
> on non-x86 machines, the stg_ap_*_ret pass parameters to it in 
> registers (as for function objects). This leads to frequent 
> crashes in GHCi on PowerPC, but not on Intel.

Ach!  Good point.  I haven't tested the newest GHC on our Sparc yet,
which is why I hadn't noticed this.

> My first attempt at fixing this (by making stg_BCO_entry push the 
> parameters onto the stack) is attached below, but I'm not 
> committing it 
> as I'm not sure it's the right way to do it. Are the stg_ap_*_ret 
> functions the only places where a BCO is entered? It might be a nicer 
> solution to modify GenApply to pass parameters to BCOs on the stack.

It's not quite right, because there might be other regs in use apart
from the vanilla regs.  I think that stg_BCO_entry can only be entered
via the stg_ap_*_ret functions, but we shouldn't rely on this.

The annoying thing is that the code for PAPs is *almost* right (i.e. in
each stg_ap_*_ret, just move the apply_fun label to the PAP case
instead), but it ends up jumping to stg_PAP_entry instead of
stg_BCO_entry.  So I've merged these two cases by storing the jump
target in a variable instead.  Try the new version and let me know if it
fixes the problem.

Cheers,
        Simon