[Oberon] Oberon for a C++ user.

[Andreas Pirklbauer]

Peter,
Sorry for the confusion in the text - I was merely referring to the potential *layout in memory*. Of course the method table as used in Object Oberon or Oberon-2 for example serves a completely different *purpose* - it contains *fixed addresses* of procedures, whereas what we need are *offsets* to procedure variables so we can find them. But apart from that it can really be the same layout in memory (side comment: note that in the case of method tables, some implementations keep it separate from the type descriptor, accessed through a separate hidden field in the heap record; but most of the Oberon-2 implementations that I have seen or done lump the method table together with the type descriptor - usually located at opposite ends of the type descriptor so that both can grow; it’s an implementation aspect only).
Perhaps you check out the implementation that I posted earlier here (see this thread). It’s all there on the Experimental Oberon Github page. The new (extended) type descriptor looks as follows:
	- - - this is the existing part of the type descriptor - - -
	1) size			(4 bytes)
	2) extends		(3x4 = 12 bytes)
	3) ptr-offsets		(Nx4 bytes, where N is the number of pointer fields)
	4) -1			(sentinel)
	- - - this is the new part that was added - - -
	5) prc-var-offsets	(Mx4 bytes, where M is the number of procedure variables)
	6) -1			(sentinel)
This, I just *added* the offsets to the procedure variables *below* the pointer field offsets, followed by (yet another) -1 sentinel. One might equally well have them placed differently, but I just wanted to have something *fast* - this solution took only 10 lines total (module ORG of the compiler + module Kernel) to implement.
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=%3CCAHXXO6EUMa0Q4mtxTJWVRvWMYc61ehwYKy20mu4M7CQNTUrPqg%40mail.gmail.com%3E>
Wed Oct 5 22:15:53 CEST 2016

Hi Andreas,


> 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).

Sorry, but the type-descriptor extensions for Object Oberon or
Oberon-2 serve a completely different purpose. First (they are called
"type-bound" procedures, right?) the entries there are *fixed*
addresses, one for each type-bound procedure. These addresses cannot
change for a given type-descriptor, unless you rearrange the module
and somehow "reload" it. Procedure *variables* don't need fixed
addresses, so there's nothing to store in a Oberon-2-like type
descriptor. If you want the GC to "mark" procedures "in use" in some
procedure variable, you need just the offset for each procedure
variable and a way to "mark" the procedure (and the module it came
from). Neither of these shows up in the Oberon-2 "method table"
approach. So if you previous work was trying to GC procedures and
modules, then I don't see how it could have worked when the design was
based on "method tables".

(It may well be that we are both saying the same thing, just not
talking in the exactly "correct" language for the other person to
understand. If that's the case, I apologize for being dense.)

> 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.

That's a bonus, makes the rest a lot easier! :-)

Best,
Peter

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