88open OCS

Stuart D. Gathman complains that the 88open OCS is braindead with regard
to the calling sequence on the 88k.


Yes, the calling sequence is suboptimal, and yes I was peeved at this when
I worked on the 88k GNU compiler for Data General (1.37 time frame). At
the time the decision was made, there were two compilers shipping to 88k
developers that I know of:


      1) The Motorola PCC port; (and)
      2) The Greenhills port.


My memory is fuzzy as to whether or not, DG had committed to the GNU C
compiler publically at that time -- I don't believe I had it was stable
enough back then. I also don't think the Tadpole compiler was released
either at that point (I don't remember what other 88k C compilers existed
at the time).


Anyway, the Motorola PCC port's calling sequence was the same as the
original FSF GNU C compiler (pass the first 8 words in registers, and pass
everything else on the stack), and the Greenhills used more or less the
current OCS calling sequence. The difference between OCS and the original
Greenhills calling sequence was how 1 word registers were returned (and
maybe passed). Since most of the vendors at the OCS meeting were using
Greenhills as the system compiler, the choice was clear. Greenhills
supposedly could not deal with splitting structures between the register
pool and the save area (even though one approach would have been to copy
the structures into the save area, like now, and then just before the
call, do 1-8 loads, to reload the registers). It evidently was an
emotional meeting, though I wasn't there.


Usually, no matter how bad a standard calling sequence is, it is better to
use the standard sequence and be able to share libraries, and such, rather
than to stand off in a corner throwing a temper tantrum.


Also, I'm surprised you were getting good results out of 1.xx. I seem to
recall that there were plenty of changes needed to get it to host itself
(those changes were deemed too large for GCC 1.xx, and were not folded in
until GCC 2.00).


| P.S.
| My 1.40 88k port did insn scheduling in the assembler. Doing it
| in the compiler can better schedule across basic blocks, but the assembler
| pass was almost as good and resulted in a much smaller and faster
| compiler. Any opinions on this? I can post my (small and simple) asopt
| pass if anyone is interested.


Sure, go ahead and post it. Tom Wood and I had added hooks in the 1.37
compiler to allow it to call an assembler optimizer between the compiler
proper and the assembler, but this was never used, since Motorola's
attempt at a scheduler (in the 0.6 release of the tools, removed in the
1.0 release) was extremely buggy.
--
Michael Meissner email: meissner@osf.org phone: 617-621-8861
Open Software Foundation, 11 Cambridge Center, Cambridge, MA, 02142
--

Return to the comp.compilers page.
Search the comp.compilers archives again.