[Oberon] Oberon for a C++ user.

[Andreas Pirklbauer]

Peter,

It is true that procedure variables are just memory addresses, i.e. "pointers" to code. However, they are not part of the type descriptor for a record that may contain such procedure variables (for details, see ORG.FindPtrFields which covers only “true” pointers, records or arrays, but not procedure variables - which have typ.form = ORB.Proc).

So one must extend the definition of the type descriptor to cover procedure variables also if one wants to implement the ability to verify whether a heap object contains a procedure variable or not. This is exactly what I did in the Ceres-Oberon implementation (at the time I more or less copied the "method table" approach implemented in Object Oberon and Oberon-2 - but without the language change).

Regarding your second point: Whether a procedure is currently running or not is not really a problem, because in Oberon 2013 the garbage collector is still only run between commands - just like in the original version of Oberon on Ceres.

Andreas

Peter Fröhlich peter.hans.froehlich at gmail.com  <mailto:oberon%40lists.inf.ethz.ch?Subject=Re:%20Re%3A%20%5BOberon%5D%20Oberon%20for%20a%20C%2B%2B%20user.&In-Reply-To=%3CCAHXXO6GP7WFc6QqBMi-_1feTTFDVU4FTRJPf_EB0QvxJBJ0X_g%40mail.gmail.com%3E>
Hi Andreas,

On Mon, Oct 3, 2016 at 12:38 PM, Andreas Pirklbauer
<andreas_pirklbauer at yahoo.com <https://lists.inf.ethz.ch/mailman/listinfo/oberon>> wrote:
> The main question is of course how does one find out whether a particular
> record found on the heap does indeed contain a procedure variable or not -
> given that the structure of the Oberon-1 type descriptor only contains
> offsets (but no "method table” as is typically used in implementations of
> Object Oberon or Oberon-2 with its type-bound procedures).

The problem is not (in my humble opinion) that you only have offsets.
The offsets are to POINTER fields of the RECORD, and (whether one uses
the word or not) procedure variables are "pointers" as well, just to a
piece of code instead of a RECORD. The problem is more that this is
*all* they are.

With a POINTER to a RECORD, I can find another type descriptor at the
"destination" and that's how the garbage collector's mark phase
proceeds through the heap. From what I can tell, adding a "procedure
descriptor" and a "module descriptor" of some sort would allow
extending the garbage collection approach to those constructs as well
(with detailed semantics obviously needing to be settled).

I consider something else "problematic" namely that you'd have to know
if a procedure is currently running; then it should obviously not be
"garbage collected" from under the CPU, regardless whether the last
"pointer" to it has been reassigned. But *if* the current Oberon still
follows the old approach of running the GC only *between* commands and
not at any other time, and *if* the current Oberon is still
single-threaded, then that "problem" actually disappears.

(Sorry, it has been too long since I seriously looked at Oberon System
variants. I demoed one for my students last year as part of the OS
course, but I didn't actually study it in any detail. It certainly
*looked* like from 1985, so maybe my knowledge of the system *is*
still applicable?)

Best,
Peter

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.inf.ethz.ch/pipermail/oberon/attachments/20161005/0ef4137a/attachment.html>