From: iainf@spider.com (Iain A F Fleming) Newsgroups: comp.editors,comp.sys.transputer Subject: Re: Folding editors Date: 20 Nov 1998 10:47:26 +0000 Organization: Spider Software Ltd Sender: iainf@belhaven.spider.com Distribution: inet Message-Id: <6r4sru1w01.fsf@belhaven.spider.com> 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> In-Reply-To: Alec Cawley's message of Thu, 19 Nov 1998 18:35:16 +0000 Xref: ukc comp.editors:32317 comp.sys.transputer:8934 The entity calling itself Alec Cawley wrote: > > The register save at the function call on a register-type processor is > thae same as register spilling by the optimiser. Less so on a decent large register-set RISC with register windows or renaming. > 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. You can indeed do this - but it is very hard to combine such a strategy with register-colouring/usage count slot allocation & reallocation - which in the general case gives the best results (smallest frame, high use in low slots) . This is why the inmos C compiler didn't do this - I did spend a little while looking at it this problem when it was proposed that the C4 ST20 cores would have the top 16 words of stack cached. Note also that if you have deeply nested blocke, presumed usage count become a rather unreliable heuristic for determining usage information -- again leading to poor slot allocation. > The optimising C compiler never worked for me at all. Worked fine for me! What were you problems? -- Iain A F Fleming http://www.spider.com/ Spider Sofware Ltd Leith Scotland +44.131.475.7045