[squeak-dev] A discrepancy between bytecode execution and simulation

Kjell Godo squeaklist at gmail.com
Wed Jan 6 02:53:42 UTC 2021


+1

On Tue, Jan 5, 2021 at 16:30 Thiede, Christoph <
Christoph.Thiede at student.hpi.uni-potsdam.de> wrote:

> > Maybe it makes sense to think in terms of "simulation depth"? In a
> non-debugging scenario, that "simulation depth" is 0 because no simulation
> code is executed. When you debug/simulate your application code, depth is
> 1. When you debug/simulate the simulation code, depth is 2. If one would
> construct deeper "simulate the simulating simulator" processes, depth can
> be greater than 2. :-)
>
> Yahoo, a Meta-Object Facility adoption for Smalltalk systems. :-) And
> depth -1 would correspond to the Slang-generated VM implementation, right?
> ;-)
>
> Best,
> Christoph
> ------------------------------
> *Von:* Squeak-dev <squeak-dev-bounces at lists.squeakfoundation.org> im
> Auftrag von Taeumel, Marcel
> *Gesendet:* Dienstag, 8. Dezember 2020 13:44:09
> *An:* squeak-dev
> *Betreff:* Re: [squeak-dev] A discrepancy between bytecode execution and
> simulation
>
> Hi Christoph
>
> > [...] between simulation and production (btw did I choose the right
> terms for them? :)
>
> Since code simulation needs code execution, I think that "simulation" is a
> part of "execution".
>
> Maybe it makes sense to think in terms of "simulation depth"? In a
> non-debugging scenario, that "simulation depth" is 0 because no simulation
> code is executed. When you debug/simulate your application code, depth is
> 1. When you debug/simulate the simulation code, depth is 2. If one would
> construct deeper "simulate the simulating simulator" processes, depth can
> be greater than 2. :-)
>
> "Production" is then simulation depth 0. :-D
>
> Best,
> Marcel
>
> Am 07.12.2020 18:55:31 schrieb Thiede, Christoph <
> christoph.thiede at student.hpi.uni-potsdam.de>:
>
> Hi all, hi Eliot,
>
>
> I constructed the following code snippet which evaluates to true when
> running it using the production execution machinery:
>
>
> nil == thisContext pop
>
>
> I guess this is fine, because what alternatives would the execution
> machinery have? It could terminate the whole VM or we could introduce
> something like #cannotReturn: for invalid stack frame objects. Probably the
> current implementation is the best despite an invalid position in
> the context stack has been addressed.
>
>
> However, the simulation machinery treats the same snippet differently, and
> it throws:
>
>
> Error: subscript is out of bounds: 0
>
>
> I wonder whether it is acceptable to have diverging behaviors for such an
> ill-defined edge case between simulation and production (btw did I choose
> the right terms for them? :)). Might it a better alternative to raise
> a Warning (#notify:) only and then return nil such as the VM appears to do?
>
>
> Best,
>
> Christoph
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20210105/34646711/attachment.html>


More information about the Squeak-dev mailing list