A.Sloman@cs.bham.ac.uk wrote:
> On Mon, 14 Feb 2005, Chris Dollin wrote:
>
>> Jonathan L Cunningham wrote:
>> ...
>> > I agree that the limit is too small, on current machines.
>>
>> If your procedure needs more than 255 locals, it's too big.
>
> Not if you are trying to develop a fortran compiler in pop11???
If the procedures of the compiler need more than 255 locals, they are
too big.
If the Fortran routines being compiled need more than 255 locals,
*they* are too big; but they're more likely to be handed to you on
a plate, immutable, and you may have to cope with them. Which you
can do, being a compiler, in the obvious straightforward pattern.
--
Chris "electric hedgehog" Dollin
>From steve@watchfield.com Mon Feb 14 10:53:58 2005
Path: news.demon.co.uk!mutlu.news.demon.net!peer-uk.news.demon.net!kibo.news.demon.net!demon!newsfeed.vmunix.org!news2.euro.net!216.196.110.149.MISMATCH!border2.nntp.ams.giganews.com!border1.nntp.ams.giganews.com!nntp.giganews.com!mephistopheles.news.clara.net!news.clara.net!valentin.news.clara.net!193.60.199.18.MISMATCH!feed2.jnfs.ja.net!jnfs.ja.net!warwick!news-out.ftel.co.uk!bhamcs!not-for-mail
From: Stephen Leach <steve@watchfield.com>
Newsgroups: comp.lang.pop
Subject: Re: Bug: clisp let* causes Stack-empty and/or runaway poplog
Date: Mon, 14 Feb 2005 10:53:58 +0000
Organization: School of Computer Science, The University of Birmingham
Lines: 32
Message-ID: <cuq28p$12aq$1@soapbox.cs.bham.ac.uk>
X-Trace: soapbox.cs.bham.ac.uk 1108380761 35162 147.188.194.39 (14 Feb 2005 11:32:41 GMT)
X-Complaints-To: abuse@cs.bham.ac.uk
X-Relay-Info: Relayed through cs.bham.ac.uk MAIL->NEWS gateway
Xref: news.demon.co.uk comp.lang.pop:1428
Hi Chris,
>If your procedure needs more than 255 locals, it's too big.
>
>If your procedure needs more than *16* locals, it's probably too big ...
Agreed - but it is still a shortcoming of the Poplog VM.
However, I think that its probably a mistake to tackle this problem
at the level of the size of the stack frame - 255 locals is plenty.
The way I would approach the implementation is to transparently
implement extra local variables into the heap. In other words, from
the 256th variable onwards, they would be assigned slots in a vector
created on procedure entry.
The only "weakness" of this approach is that Poplog processes have
a long-standing bug that means they do not handle type 3 lvars
correctly. Type-1 and 2 lvars are copied but type 3 lvars are shared.
This same defect would apply to these overspill variables, too. But
that really implies it is about time that bug got fixed.
Sure, it is a bit more work - but it is bound to give more
satisfactory runtime performance and be a better match for more
machine architectures.
--
Steve
[Forwarded to comp.lang.pop by A.S.]
====
Aaron Sloman, ( http://www.cs.bham.ac.uk/~axs/ )
|