[eresi-dev] Upcoming improvements in ERESI CVS (0.8 alpha)

[Julien Vanegue]

Hello all,

Let me give some news about what Ive been doing recently in
the ERESI code that I havent commited yet, but that should be
in CVS some time soon:

* Improvements of libmjollnir.

- I have almost finished to unify the storage of analysis information
whatever the container data type. In my code, I do not have anymore
the (almost) duplicated functions for blocks and functions
store/save/load information. Just 1 API now !

- I moved links of containers for using our new list_t data structure.
This will allow us to do a "foreach" on the list of all container links.

-  Containers  ->type field now is a real eresi typeid and not a
pseudo-bastard type of  some hidden enum in libmjollnir, like
previously. This makes containers potentially usable for any kind
of data structure and not only basic blocks or functions.

* Auditing of the eresi meta-language semantics.

- I have formally defined the complete operational semantics of ERESI
commands in the form of an axiomatic semantics. Ask me my draft
article if you are interested (unreleased yet).

- I debugged (and still debugging) problems in the eresi language related
to nested foreach. I implemented linear annotations for list and hash
tables, so that it is not possible to iterate a list or hash when its 
already
being iterated. That will avoid inconsistency / unwanted variable aliasing
that could make an eresi program to bug badly, but yea, it restricts the
possible written eresi programs. I am sure this feature should never be
used in any working program, so I have chosen to implement this system
instead of letting this behavior "at the choice of the user" (too dangerous)

- I am debugging an issue on hash/list when inserting objects. Currently,
the key of an inserted object is generally its value itself ! (like on hash
tables or list of string or integer, the key of the element is its 
value). This
is a big design choice, because the elements might be updated in the
list, so keeping the key to the very first value an element had is I think
inconsistant. I am still not sure what is the best key to use for list 
elements,
any idea ? The key is useful to access the element like : $list[key], so
its important to choose a good key. The key should not be related to
the value of the object because its value can change. Its problematic
because, until now, it was very practical to add an object to the a list
or hash table, like :

add $list[somekey] immed_integer_or_string

Thus we have simply no other information to use as the key, only the
value ! Help is needed here, do you have any idea ?

- I am doing more merging on the system of revmexpr_t / revmobj_t. This
includes being able to print expressions at an intermediate depth (e.g. not
root depth neither terminal depth). This was requested by pouik and I
think indeed it is very useful.


That is it. Those things -must- work before program transformation
is operational. Else the language will be too painful to use.

My personal TODO after those things are finished:

* Add support for bitfields in the type system.
* Make the very first program transformation to work
* Add dataflow commands

As always, help is welcome.

Julien Vanegue