🚀 go-pugleaf

In article <9002240636.AA08346@pozzo> taylor@THINK.COM (David Taylor) writes:
>I built gcc 1.37.1 as a cross compiler on a vax running Ultrix 3.1.  The
>links are:
>
>	aux-output.c --> ../config/out-ns32k.c
>	config.h --> ../config/xm-vax.h
>	md --> ../config/ns32k.md
>	tm.h --> ../config/tm-pc532.h
>
>[I'm trying to get it to generate code for a 32532 based personal
>computer; since I don't have the machine built yet, much less have an
>operating system for it, I'm trying to run gcc as a cross compiler.]
>--
>David Taylor
>taylor@think.com, ...{ames,bloom-beacon,harvard}!think!taylor

I'm in the midst of a similar task...  And had a different
question about the function prologue and epilogue.  There are
two instructions, enter [], and exit [], that are intended to
save and restore callee used registers.  I am not that familiar
with the ns32k and the data sheets aren't that informative in 
a couple of areas, so I have a couple of questions:

1) Does the enter [] instruction save the registers in the
frame in addresses {smaller|larger} than where the PC is stored?

2) If there are in fact stored registers on procedure entry, then
the offset of the first argument from the FP is not a hard 8 as
this declaration (from config/ns32k.h) would suggest:

/* Offset of first parameter from the argument pointer register value.  */
#define FIRST_PARM_OFFSET(FNDECL) 8

Is it instead something that looks like:
	8 + (#of_regs_stored_in_[]_mask * size_of_a_register)


Am I confused here?  What has me mystified here is the dichotomy between
a belief that it sort-of works as is (due to current use and all), and
the apparent brain-damage of not knowing how big your call frame is...
Now if the ns32k really has an AP and I don't know about it, then this
is all academic...

Thanks.
------------------------------------------------------------------------------
Jon Loeliger			    | loeliger@convex.com
Convex Computer Corporation	    | I'm the thirteenth at your table,
3000 Waterview, Richardson TX 75080 | I'm the uninvited guest.  - Marillion
--
------------------------------------------------------------------------------
Jon Loeliger			    | loeliger@convex.com
Convex Computer Corporation	    | I'm the thirteenth at your table,
3000 Waterview, Richardson TX 75080 | I'm the uninvited guest.  - Marillion

When compiling gcc 1.37.1 I'm getting a core drop as well.  The system
is a Data General AViiON (88000)

The culprit in this case is gnulib as well.


% make
        for name in _adddi3 _subdi3 _muldi3 _divdi3 _moddi3 _udivdi3 _umoddi3 _n
egdi2  _anddi3 _iordi3 _xordi3 _lshrdi3 _lshldi3 _ashldi3 _ashrdi3 _one_cmpldi2
  _bdiv _cmpdi2 _ucmpdi2 _fixunsdfdi _fixdfdi _floatdidf _varargs; \
        do \
          echo    .
        do \
          echo ${name}; \
          ./gcc -B./ -fstrength-reduce -O -I. -I. -I./config  -c -DL${name} ./gn
ulib2.c -o ${name}.o; \
          ar rc gnulib ${name}.o; \
          rm -f ${name}.o; \
        done
_adddi3
./gcc: Program cc1 got fatal signal 11.
*** Error code 1

Stop.
%

A stack trace of this from sdb reveals.....

% sdb cc1 core
0x33ef4 in split_tree:712:   if (TREE_CODE (in) == code
*t
split_tree()   [fold-const.c:712]
fold()   [fold-const.c:1412]
build_binary_op_nodefault()   [c-typeck.c:1619]
build_enumerator()   [c-decl.c:3435]
yyparse()   [c-parse.tab.c:92]
compile_file()   [toplev.c:1118]
main()   [toplev.c:1995]
*