From: Alec Cawley Newsgroups: comp.editors,comp.sys.transputer Subject: Re: Folding editors Date: Thu, 19 Nov 1998 18:35:16 +0000 Organization: Lost in the Wilderness Distribution: inet Message-Id: References: <36374B57.168B9492@pact.srf.ac.uk> <71aj0c$oc$1@fangorn.moria.de> <6r1znq7264.fsf@belhaven.spider.com> <3639BEFD.2CC25E3C@esgem.com> <6r4ssm59ay.fsf@belhaven.spider.com> <6rhfwi4ee6.fsf@belhaven.spider.com> <363EEB84.5CAD538B@roke.co.uk> <6rvhkw20nk.fsf@belhaven.spider.com> <364CBB49.ABE8624B@oucs.ox.ac.uk> <6r90hb7vgg.fsf@belhaven.spider.com> <3651C1BA.16126C2@roke.co.uk> <6rk90t464b.fsf@belhaven.spider.com> Mime-Version: 1.0 Xref: ukc comp.editors:32312 comp.sys.transputer:8933 In article <6rk90t464b.fsf@belhaven.spider.com>, Iain A F Fleming writes > >The entity calling itself Richard Beton wrote: >> >> I'm not sure whether the compiler optimisation is necessarily hindered by >> deep folding, although with some languages and some compilers I wouldn't >> be surprised. > >On the Transputer, efficiency of instruction coding (density) is affected by >stack offset a variable is placed at. Deep nested blocks, with variables >live across the inner blocks, hinders placing all heavily-used variables at >lower slots (>16). Moving inner blocks to independent functions (in the >Transputer C compiler, at least) could well reduce code size, and improve >speed. (I know this as I wrote parts of both the inmos Occam & C compilers.) >On other architecures, the equivalent cost will be register spilling. The register save at the function call on a register-type processor is the same as register spilling by the optimiser. On a transputer-type processor, the optimiser always has the option of creating a new frame, with a new set of 16 fast-access slots. In both cases, the optimiser can create an "internal function" which will be no less efficient than an external function, and will save the call/return instructions, plus associated pipeline bubble. The same logic applies to the fold seen as a design aim. It is always the duty of the designer to spot common patterns and make them into functions. Those who can or do not do so may use folding to paint over their mistakes. However, any competent designer will spot the common pattern at the pattern (i.e. design) stage of development before the question of folding arises. If the pattern is only used once, it is not obvious that the code is better separated out and moved several screens-full away. If the code is a natural black box, the designer will have spotted this fact and made a function. If it is just a block of co-located code, I do not think it aids design to make it into a function just because the nesting depth is getting a bit high. >Also, determining data-flow in any program is always a worst-case. As you >make the program more complicated, the more pessimistic the compiler will >become. Common sub-expression analysis becomes less tractable. Achieving the above, however, may be difficult. >> In occam, the nesting depth would be no hindrance to compiler >> optimisation and could possibly aid it. > >Assuming that you had an optimising Occam compiler. As far as I know the >inmos optimising Occam compiler, although very good, never (officialy) >escaped from Aztec West. The optimising C compiler never worked for me at all. -- Alec Cawley