Re: matrix linking

[george at georgeshagov dot com]

Mike, sorry for not answering.

I think the idea of matrix linking is quite different, let me try to
explain. I
would not say the matrix linking is the bynamic bunding, or rather to
say it is
not only the dynamic binding. Let us consider a sample:


void foo()
{
   printf(?foo\n?);
}

int main(void)
{
   foo();
   return 0;
}


Being compiled this sample will give us an executable module. If it be we are
going to change the algorithm of the function foo we need to recompile the
module and reload it to the system, commanding dynamic binder to use newly
compiled function foo instead of the previous one. How particularly it might
look like it depends on realization of the dynamic binder.
The approach proposed in matrix linking is intended to do very similar
job with
one exception. In this particular sample we actually have two modules, the
first is ours, the second is the one, providing functionality of printf
function, libc, for instance.  (I am attaching the picture)

So, the matrix linking approach says we will have matrix compiled as
two arrays
(rows) of the pointer, one is ours the second for libc functions. It means it
is possible to substitute not only a foo function, but also a printf one.

I am not going to analyze which particular benefits it might give. What I am
saying that the intention of matrix linking is rather an approach to system
development and their integrations.

Let me add one more thing here. Regarding the posted sample. Let us say
we have
libfoo (our) module and libc modules. Supposing we would like to substitute
printf function, for this purpose we have compiled libc_custom module within
re-implemented printf (for instance). Thus we have got our system working
properly. Let us say we need to restart our system. Does it mean we need to
instantiate our binder (which makes the matrix) once again by libc_custom
module? It is not necessary, since it is possible to dump that state of the
matrix and after restart just reuse the previous state. In our case the state
of the matrix might look like this:

<matrix>
<row id=0>
  <modules>
     <module value=?libc?/>
     <module value=?libc_custom?/>
  </modules>
</row>
<row id=1>
  <modules>
     <module value=?libfoo?>
  </modules>
</row>
</matrix>

It might have looked like this is a question of customization. It is
possible to
argue the case, yet to me it serves much wider needs.

regards.

Quoting Mike Stump <mrs@apple.com>:

> On Jan 18, 2006, at 10:24 PM, george@georgeshagov.com wrote:
> > I thought some kind of that, yet moved to matrix approach. Reason?
> > The clarity.
>
> Clarity is not an in-vogue reason for compiler code generation.  Size
>  is, speed is.  Sacrificing these two for clarity in generated code
> limits the end result to that of novelty item.
>
> > For instance you have many ... let me say 'revisions' of the same
> > function.  In
> > your case it is obvious how to handle jump to the newly compiled
> > function, but
> > how to handle roll-back to some particular revision of this function?
>
> If my scheme supports changing from X' to X'', then clearly it
> supports changing from X'' to X'.  Just google undo buffer for an
> example algorithm that will do this.
>
> > How about revisioning for file and for module?
>
> A file is just a collection of units, if you can do a unit, you can
> do a file (let me ignore file scope ctors/dtors for a second).
> Module, what's that?
>
> > These thought restrained me from doing any assembler hacks into the  system.
>
> Modifying the assembler would be bad.
>
> > One more thing. My original purpose was to make possible to modify the
> > algorithms runtime, without recompilation. For this case we need
> > interpreter.
>
> If you're intention is to write an interpreter, that this is
> orthogonal to runtime rebinding.  This list would be off-topic for
> discussing writing a C interpreter.
>
> > you may find this topic interesting:
> > http://docs.georgeshagov.com/twiki/tiki-index.php?page=Matrix
> > +Linking+-+Proxing)
>
> Can't manage to read it, posting links I can't read is bad style.
>
> > Synchronization and other challenges.
> > Mike, do you have a copyright on that phrase: "there are certain
> > realities when
> > doing this,  and its important to understand the limitations and
> > gotchas. " ?
>
> Yes, US law makes everything I write copyright.  :-)/2
>
> > About my initial approach. I completely reviewed it :-). it looks
> > like this:
> > http://docs.georgeshagov.com/twiki/tiki-index.php?page=Matrix
> > +Linking+-+The+shortest+way+to+go,
> > it would appear it is required to make an additional pass in order
> > to formalize
> > the matrix.
>
> This looks all wrong.  See Objective C for an example of a
> dynamically rebindable language, further, you can examine the code
> generation, the data structures and runtime library to see how they
> achieve things.  It doesn't need mlmake and doesn't need 'new passes'
>  run by make.  For example, you can see the gcc darwin port for how
> to  generate a stub function that does some arbitrary thing inside a
> compiler.
>
> > Dear Mike, I would be really interested in some questions regarded  runtime
> > linker. I am going to download the sources, yet in that same time  if it be
> > there is any additional dos about that, I would be really
> > appreciate for the
> > link.
>
> If you're talking about the runtime rebinder we use, don't know of
> any.  For a generic runtime linker, google("ld.so") will take you to
> the sources for one.

Attachment: ml_dynamic_bind.gif
Description: GIF image