[virtmach] bytecodes and stacks

[Mark W. Humphries]

The following mail, dated 11/30, is the most recent I've received from this
mailing list. Has there been any more recent activity on this group? Or have
I been inadvertently (I hope) kicked off? :)

Thanks,
 Mark W. Humphries

-----Original Message-----
From: Stephen Pelc <sfp@mpeltd.demon.co.uk>
To: virtmach@iecc.com <virtmach@iecc.com>
Date: Wednesday, December 01, 1999 6:02 PM
Subject: Re: [virtmach] bytecodes and stacks


>Date sent:      Tue, 30 Nov 1999 20:45:16 +0000
>From:           Ceri Storey <cez@nomorespam.freeserve.co.uk>
>To:             virtmach@iecc.com
>Subject:        Re: [virtmach] bytecodes and stacks
>Send reply to:  virtmach@iecc.com
>
>Ceri Storey said:
>> personally, i can't see why why two stacks would be a better solution,
>> since when the machine returns from a function, the arguments bound
>> in that procedure will be lost forever, and if a two stack model were
>> used, the virtual machine/ programmer would need to pop the excess data
>> from the data stack.
>The advantage of a two stack VM is that it allows any number of
>results to be returned by a procedure. The traditional C style
>"stack" is more properly a list of frames in which each frame is
>built and released as a whole. In a stack machine each item on
>the stack can be dealt with individually. Having a separate
>return stack avoids having the return address amongst procedure
>parameters and results, and thus permits more flexible data
>handling.
>
>However, when we designed two stack VMs to run C efficiently
>(see the OTA specifications at www.europay.com) we added
>additional VM support for frames. The canonical Forth stack
>machine is not suitable for frame construction in which it is
>assumed (as C and many other languages do) that the frames are
>in main memory.
>
>Stephen
>
>--
>Stephen Pelc, sfp@mpeltd.demon.co.uk
>MicroProcessor Engineering Ltd - More Real, Less Time
>133 Hill Lane, Southampton SO15 5AF, England
>tel: +44 1703 631441, fax: +44 1703 339691
>web: http://www.mpeltd.demon.co.uk
>