[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Pnet-developers] libjit - separation of interfaces
From: |
Miroslaw Dobrzanski-Neumann |
Subject: |
Re: [Pnet-developers] libjit - separation of interfaces |
Date: |
Thu, 3 Jun 2004 16:54:47 +0200 |
User-agent: |
Mutt/1.4i |
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