[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [Gcl-devel] Re: gcl/maxima on hppa



Greetings!  Almost there on hppa.  Using Lamont's latest assembler in
place of setjmp, I can compile the whole thing without (obvious) gc
errors.  I still have some problems running maxima's test suite, on
this platform, alone now of all 11 Debian platforms.  They seem to
persist regardlesss of compiler version (3.0 or 3.1), and memory
alignment, (4 or 8 byte boundaries).  I suppose I could try 16 byte
alignment, but this seemed to be a preference, not a necessity, from
earlier postings.

Here is the GC patch:

=============================================================================
#if defined(__hppa__) /* Courtesy of Lamont Jones */
/* the calling sequence */
struct regs {
	void *callee_saves[16];
};
void hppa_save_regs(struct regs);

/* the code */

	asm(".code");
	asm(".export hppa_save_regs, entry");
	asm(".proc");
	asm(".callinfo");
	asm(".label	hppa_save_regs");
	asm(".entry");

	asm("stw	%r3,0(%arg0)");
	asm("stw	%r4,4(%arg0)");
	asm("stw	%r5,8(%arg0)");
	asm("stw	%r6,12(%arg0)");
	asm("stw	%r7,16(%arg0)");
	asm("stw	%r8,20(%arg0)");
	asm("stw	%r9,24(%arg0)");
	asm("stw	%r10,28(%arg0)");
	asm("stw	%r11,32(%arg0)");
	asm("stw	%r12,36(%arg0)");
	asm("stw	%r13,40(%arg0)");
	asm("stw	%r14,44(%arg0)");
	asm("stw	%r15,48(%arg0)");
	asm("stw	%r16,52(%arg0)");
	asm("stw	%r17,56(%arg0)");
	asm("bv	0(%rp)");
	asm("stw	%r18,60(%arg0)");

	asm(".exit");
	asm(".procend");
	asm(".end");
#endif

void
mark_c_stack(jmp_buf env1, int n, void (*fn)(void *,void *,int)) {

#if defined(__hppa__)
  struct regs hppa_regs;
#endif
  jmp_buf env;
  int where;
  if (n== N_RECURSION_REQD)
    c_stack_where = (long *) (void *) &env;
  if (n > 0 ) {  
#if defined(__hppa__)
    hppa_save_regs(hppa_regs);
#else    
    setjmp(env);
#endif
    mark_c_stack(env,n - 1,fn);
  } else {
      
    /* If the locals of type object in a C function could be
       aligned other than on multiples of sizeof (char *)
       then define this.  At the moment 2 is the only other
       legitimate value besides 0 */
    
#ifndef C_GC_OFFSET
#define C_GC_OFFSET 0
#endif
    if (&where > cs_org)
      (*fn)(0,cs_org,C_GC_OFFSET);
    else
      (*fn)(cs_org,0,C_GC_OFFSET);}
=============================================================================

1) Still would like to know whether this indicates a setjmp problem.
gcl uses setjmp elsewhere.

2) Are there any particular structures, like file pointers, which
*must* be aligned on 16 byte boundaries?  Would this be likely to
clear up anything?  ( My guess, no)

3) Outside of 'growing up', the stack behaves normally, right?  The
boundaries can be taken by beginning and ending local variable
addresses?

4) Does hppa treat functions returning a pointer differently from
   functions returning a long, i.e. place them in different registers?  
   The m68k fix I just put in seemed to help this build too.

5) Need I try setjmp *in addition* to the assembler, or are they
   basically just replacements?

I'll try to find time to analyze these failures with gdb soon,  Please
excuse the preliminary nature of this report.


Take care,


-- 
Camm Maguire			     			camm@enhanced.com
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah



Reply to: