X-Received: by 10.55.98.194 with SMTP id w185mr21656385qkb.34.1520624903232; Fri, 09 Mar 2018 11:48:23 -0800 (PST) Path: csiph.com!weretis.net!feeder6.news.weretis.net!feeder.usenetexpress.com!feeder-in1.iad1.usenetexpress.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!r16no1655980qtn.1!news-out.google.com!b37ni172qtk.0!nntp.google.com!peer01.iad!feed-me.highwinds-media.com!news.highwinds-media.com!post01.iad!fx40.iad.POSTED!not-for-mail From: Robert Wessel Newsgroups: comp.lang.c,comp.sys.raspberry-pi,comp.programming Subject: Re: Compile Assembly and C files together Message-ID: References: <87muzh4nhk.fsf@LkoBDZeT.terraraq.uk> <9EwoC.76436$CL3.51040@fx17.am4> User-Agent: ForteAgent/7.20.32.1218 MIME-Version: 1.0 Lines: 47 X-Complaints-To: abuse@easynews.com Organization: Forte - www.forteinc.com X-Complaints-Info: Please be sure to forward a copy of ALL headers otherwise we will be unable to process your complaint properly. Date: Fri, 09 Mar 2018 13:48:20 -0600 X-Received-Bytes: 3647 X-Received-Body-CRC: 1107187243 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Original-Bytes: 3503 Xref: csiph.com comp.lang.c:127590 comp.sys.raspberry-pi:16649 comp.programming:8452 On Fri, 9 Mar 2018 19:20:01 +0100, David Brown wrote: >On 09/03/18 18:19, Robert Wessel wrote: >> On Fri, 09 Mar 2018 17:16:19 +0100, David Brown >>> Well no, of course it was not a priority. Why should it be? Virtually >>> no one is interested in the calling conventions - just compiler writers, >>> people writing OS context switch routines, and the few dozen people >>> writing assembly routines instead of using higher level languages. >>> Efficiency of generated code was far and away the priority when AMD made >>> the System V AMD64 ABI used by everyone except Windows. $DEITY only >>> knows what MS's priorities were when they scrambled it and made >>> something pointlessly different and less efficient - the only think I >>> can think of was to make implementation of "printf" a little easier for >>> the MSVC compiler writers. >> >> >> While I'm not going to try to defend it, MS's explanation is that >> there's no cost to actually allocate the spill space (just a change to >> the stack adjustment done at entry to the calling function, and the >> space is not usually wasted (and thus does not impact caching), >> compilers can use it for local variables if they're not going to spill >> the first four parameters to that space. And it does, of course, make >> the variadic parameter thing easier. > >That is an interesting view on it - thanks. > >However, it /will/ have a cost in the case of functions that do not >otherwise need to allocate space in the stack other than the automatic >push/pop from the call/ret pair. So a small function that could >otherwise be run entirely from within the caller-saved registers, but >which itself calls another function, will need to allocate stack. This >might seem rare, but I am sure it turns up a lot in C++ code with all >these functions that don't seem to do anything except pass on >responsibility to other functions! While true, most of those small C++ functions need to set up a stack frame anyway so that exception handling can unwind the stack. That doesn't, however, change the fact that the shadow area allocation is a waste of cache space in that scenario. OTOH, many of those short functions *should* get inlined. Obviously that's more difficult if the short functions are virtual ones, but if you're clunking your way through a indirect call via a vtable anyway, the added pain from half a wasted cache line is probably modest.