Re: [Pnet-developers] libjit - separation of interfaces

[Miroslaw Dobrzanski-Neumann]

On Thu, Jun 03, 2004 at 08:16:41PM +1000, Rhys Weatherley wrote:
> So, you want to throw away all of libjit and implement something completely 
> different from scratch that has the same API?  Why not just modify libjit to 

No, not truly for the next 8-10 years, but it would be a nice excercise. I my
spare time, when the kids are sleeping, I can hardly implement a jit.
But I will still provide small patches and do code reviews.

> include whatever optimisations you are interested in and leave the bulk of 
> the framework intact?  If the framework has deficiences for your purposes, 
> they can be addressed.

One of them is described in "Why GPL".
It would be nice to make public interfaces (include/jit/*) royalty free also
LGPL if someone wants to stick the the interface but *must* reimplement it
from scratch.

> 
> > In my opinion jit-block.h does not belong to public frontend interface
> > because it presents the internal implementation details
> 
> By that rule, the whole of jit-insn.h is internal implementation detail, 
> because the API is predicated on front end treating it like a three address 
> system.  Other representations will need other API's.  Without jit-insn.h, 
> there is no JIT at all.

This is not true.

Looking at an component one can distinguish two aspects:
- WHAT it is doing
  parts or all of it may belong to the public interface
- HOW  it is doing
  nothing of if may belong to the public interface

What jit-insn.h says is: I can do the following ... For example
 - r = jit_insn_add (f, v1, v2)
      This reads as follows:
      Dear jit do the following thing for me ...
      This is a WHAT

 - jit_insn_label (f, &label)
      This reads as follows:
      Dear jit mark the current position with label
      This is a WHAT


With jit-block.h tells an another story. For example
 - b = jit_block_from_label (l)
      This reads as follows:
      Dear jit give me internal representation of something where my marker
      lives
      This is a HOW because:
      * It says there is something as code block to which the label is
        attached.
      * The creation of code blocks and distribution of labels happens in the
        background but parallel to the process intermidiate code generation
 - jit_block_is_reachable ()
      In the background happens even more viz control flow analysis is
      performed as you go.
      This says HOW it is implemented

With the jit_block_*() interfaces the client may expect the block information
is always available.
Can you guarantee that for any future implementation?

If you say yes imagine the following situation.

You have discovered a perfomance problem (speed, memory, ...). So you decide
not to partition the insn stream into blocks until entire function has been
completely translated that is until jit_function_compile () has been called.
The jit_block_*() cannot be implemented correctly before the partitioning has
taken place but the frontend expects them to work at any time.

Let's take a look at dpas-parser.y
IfTail : Statement K_ELSE
         {
                 if (! jit_block_current_is_dead ())
                 {
                         ...
                 }
         }
         Statement ;

Why does it use the jit_block_current_is_dead() function? Obviously it has
forgotten what it has done till now. This is a book-keeping problem.

> 
> Cheers,
> 
> Rhys.
Cheers,
        Mirosław
-- 
Mirosław Dobrzański-Neumann
E-mail: address@hidden

This message is utf-8 encoded