Path: utzoo!attcan!uunet!samsung!brutus.cs.uiuc.edu!jarthur!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: <1989Nov16.201135.4395@paris.ics.uci.edu> Date: 17 Nov 89 04:11:35 GMT References: <1948@psueea.UUCP> <1989Nov14.175806.23483@paris.ics.uci.edu> <5352@orca.WV.TEK.COM> Reply-To: Ron Guilmette Organization: University of California, Irvine - Dept of ICS Lines: 39 In article <5352@orca.WV.TEK.COM> andrew@frip.wv.tek.com writes: > > "(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." > >Registers r14 and up are preserved. That's more registers than those >good ol' CISC machines preserved. But of course, that's not the point Andrew. If we can do better still with this hardware, why not try? > > "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)." > >Not at all. If you have the global program view necessary to do >graph-coloring (you are generating the code for all calls to the >caller), then it's fairly obvious that you can generate any code you >want, and need not conform to the standard interface. The OCS serves >only to guide compilers/linkers in making procedure interfaces for >callers that they do not control. But in practice, you can still do graph coloring register allocation *without* perfect (ultra-global) information about standard library routines and if you try to do this, you will be better off (performance- wise) if you can allocate more registers because you know that they will not be clobbered across calls to library routines. Right now people can't take advantage of this possibility because the OCS is treated as gospel for the building of standard libraries, meaning that users of those libraries, even if they have otherwise perfect global data-flow information or *their* routines are still forced to do unnecessary stores and reloads of registers across calls to the standard library routines. // rfg