Mixed stuff

[Hans-Dieter Dreier]

Matthew Tuck schrieb:

> Hans-Dieter Dreier wrote:
>
> > Let's say there are two sorts of information:
> > 1. About interface - what you call type signature. It must be the same for all
> > possible implementations.
> > The compiler checks it to verify that the program conforma to the specs.
> > 2. About implementation - if you don't have a better name, we could name that
> > impl signature. It may be different for different implementations. It is used
> > to control code generation.
>
> Hmm, so the code generation info is in the impls?  What sort of
> information would this be?

For example, whether a feature uses get/set calls or direct variable accessor direct
read access and set function calls.

> > > > Interesting idea, hmmm... Certainly this involves a lot of fixups
> > > > at link time, but it *could* be done if an executable is constructed
> > > > the usual way.
> > > That depends what you meant by usual way ... the usual way as I know it
> > > is machine code generation before linking, hence prohibiting this.
> > Not at all. It's just that the linker needs to do lots of fix-ups. Everywhere a
> > member offset is needed. Unless you want to exchange variable accessed with
> > function calls; then it's a completely different affair.
>
> Not really, it's just an offset into a vtable still, which still needs
> to be laid out in the same way.

The same vtable slot can be used, that's true.The *code* to access that feature is
different however
unless everything is accessed by a method call (which is rather inefficient).

> This sort of fixup would seem to be the only way to achieve run-time
> type/impl loading.  A fixed layout could be used to achieve default
> offsets.

If the user changes implementations I'd think a recompile is OK becauseit doesn't
occur too often. I think your run-time type/impl loading would
involve having every feature being accessed through a vtable.
Either this indirection is resolved by the linker
(but then the linker must know when true "virtual" access is meant and therefore
no indirection resolution may be done) or it comes with a hefty performance hit.

And because the link phase must be done on every load if the properties of the impl
to be loaded is not known in advance, this might slow down loading considerably.

But maybe proceedings as you see them are still not clear to me.

> > And why is it better than compiling the whole stuff into
> > an executable and omitting the link/code gen phase?
>
> How could you omit the link/code gen?  Linking is required to support
> multiple modules, and code gen (if not interpreting ASTs), is necessary
> to convert to the resultant code.

At the beginning we will most likely just interpret ASTs, I think,so there is no
"code gen" other than producing an AST or some equivalent that
is better suited to interpretation.
And since we can expect to have the other modules already loaded into memory,
linking can be done by the compiler as well.

But I really think that we need not discuss these details now if we do not
make decisions that could have an adverse impact on flexibility.

> >> Yes, but how do you handle the problem of dynamic dispatch?  GC
> >> generally are written for finding out the pointers easily.  We would
> >> certainly have to do some extension of parameterisation of code to do
> >> this as far as I can see, although it looks like could be done.  It
> >> might be very difficult with incremental collectors though - if you're
> >> interested in taking this any further maybe the GC list might be the
> >> place to ask.
> > I can't see how dynamic dispatch could be a problem for GC. Dynamic dispatch
> > uses pointers too, doesn't it? And they have to be reachable, otherwise
> > dispatch couldn't use them. Since we construct our memory layout in a way that
> > allows GC to identify every reference, they are subject to GC. There is no
> > scenario I can imagine right now where an object could be collected and
> > shouldn't. If it can't be reached, it is indistinguishable from not being there
> > at all. (It's the same as in physics: If you postulate an effect that can't be
> > observed, then it's the same as if there was no effect).
>
> Hmm, are you referring to run-time or compile-time here?

In principle it makes no difference. If something cannot be reached immedediately
after compile time, it can never be reached, so it can be collected.It may occur that
something (even code) becomes unreachable during runtime as well.
It completely depends on the reference structure we choose - so we may choose it with
GC in mind, or we need to NULL out pointers ourselves.
The nice thing about GC (in a GC friendly environ) is that it automatically collects
what can collected but nothing more.

> --
>      Matthew Tuck - Software Developer & All-Round Nice Guy

--

Regards,

Hans-Dieter Dreier
(Hans-Dieter.Dreier@materna.de)