Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!shadooby!samsung!usc!ucla-cs!uci-ics!rfg
From: rfg@ics.uci.edu (Ron Guilmette)
Newsgroups: comp.sys.m88k
Subject: Re: Info about the 88open Consortium and standards
Message-ID: <1989Nov14.175806.23483@paris.ics.uci.edu>
Date: 15 Nov 89 01:58:06 GMT
References: <1948@psueea.UUCP>
Reply-To: Ron Guilmette <rfg@ics.uci.edu>
Organization: University of California, Irvine - Dept of ICS
Lines: 30

In article <1948@psueea.UUCP> bruceco@jove.cs.pdx.edu (Bruce Coorpender) writes:
>The 88open Consortium was mentioned in a recent article. It is
>
>Binary Compatability Standard (BCS)
>Object Compatability Standard (OCS)

I have a technical question about the BCS and the OCS.

I was unhappy to see that these two standards have mandated (for those who
choose to adhere to them) what I believe is a somewhat sub-optimal function
calling sequence.  While it is true that the abundance of registers on the
88k does significantly improve the efficiency of parameter passing in the
great majority of cases, I have been distressed to see that (a) you
are limited to passing at most 8 words worth of actual parameters in
registers (which seems an unnecessary and artificial limit to me) and
(b) more significantly, there seems to have been a major departure from
the common practice in the good ol' CICS days when callers could assume
that almost all registers (except for the one which got the return value)
were *preserved* across a "standard" call.

It seems to me that (b) effectively ties the hands of many otherwise very
sophisticated modern optimizers (with nice graph-coloring register allocators
of course).

Am I right that this is an artificial "man-made" performance barrier?  If
so, what was the motivation?

Inquiring minds want to know! :-)

// rfg