\chapter{Conclusions and recommendation}
\label{cha:conclusions}


This chapter will present the conclusions on this thesis in
section~\ref{sec:concl-concl}.  Then section~\ref{sec:recomm} will
present the recommendations for this thesis.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Conclusions}
\label{sec:concl-concl}

This section will give conclusions on all topics covered in this
thesis. First, subsection~\ref{ssec:concl-end} will present conclusions on the
endianness port. Subsection~\ref{ssec:concl-limm} will present
conclusions on the long immediates implementations. Finally,
subsection~\ref{ssec:concl-general} will give some general conclusions 
on the whole graduation process.


\subsection{Endianness}
\label{ssec:concl-end}
The original problem of the endianness port of the MOVE framework was
twofold. On one side it was desired to run the tools on (cheaper)
little-endian machines, instead of on big-endian Suns and HPs, as done 
so far. On the other side a certain realization of the MOVE framework
at NEC was to be embedded in a little-endian chip. Therefore is was
desired that the MOVE framework was to be made target-endianness
aware. Both problems have a lot in common with each other, so it was
natural that both problems were solved at the same time. 

Both problems were solved for all parts of the MOVE framework: the
front-end consisting of the GCC compiler, the GNU assembler, linker
and bintools, and the C system libraries, and the back-end, consisting
of the {\tt sched} source that is used to build the scheduler,
simulator, and various helper tools.

The result is a framework that can be either compiled for
little-endian or big-endian target, by setting a Makefile switch at
compile time. This framework can then be installed in parallel to a
framework of different target-endianness on one machine. The
intermediate files are host-endianness independent. One can take any
intermediate file, such as objects, binaries and profiling
information, and process them further on a machine that has a
different host-endianness than the machine where that file was
generated.




\subsection{Long Immediates}
\label{ssec:concl-limm}
The original problem of the long immediates was to find a better way
to schedule long immediates. The old framework used dedicated
immediate fields alongside the instruction word. The goal was to get
rid of these dedicated fields and use ordinary move slots for storing
immediates. 

An implementation, dubbed the ``resource variant'' was developed. It
is called the ``resource variant'' since the only way to track the
immediates in the move slots is by checking various resource tables
such as the immediate register's occupation and the contents of a
special tag in each instruction word. The method followed is to first
completely schedule the use of the immediate (e.g. the {\tt i0~->~r3}
move), after which a special routine tries to schedule the immediate
definition (e.g. the {\tt \#~->~i0} move). Also taken into account is
the backtracking of scheduling, the so-called ``killing'' and
``unkilling'' of nodes. 

This resulted in an implementation that adds between 1 and 5 percent
to the instruction count. This increase is low compared to the number
of moves actually containing an immediate, which can be between 10 and 
30 percent. It turns out that most
immediate writes are scheduled in otherwise empty move slots. Also,
take into consideration that since the dedicated immediate fields are
not needed anymore, the total code size (instruction count multiplied
by the instruction word length) decreases, up to 20 percent for some
configurations. 

A comparison with another implementation of Long Immediates in the
MOVE framework was conducted. This other implementation, dubbed the
``pseudo move variant'' uses pseudo-moves to represent the immediate
writes like {\tt \#~->~i0}. This gives this implementation a better
flexibility to schedule these immediate writes, but it is more limited
in flexible immediate register configurations, a feature of the
``resource variant''. Both implementation achieve about the same
performance in terms of instruction count.  Regarding implementation
costs, it was expected that the ``resource variant'' would be easier
to implement, since all code was hooked from one point in the
scheduler. In the end this expectation did not come true, since
several unexpected bugs turned up in various parts of the code. The
amendments made to the data structures with the expected, documented
behavior in mind, triggered several bugs that expected a different
behavior. Closer look at the documented API revealed that the API was
indeed ambiguous at some points. Fixing the triggered bugs to make the
whole framework consistent again broke the paradigm of a clean code
interface. Concluding we can say that one of the planned main
advantages of the ``resource variant'', this clean code interface, did
not hold.


\subsection{General}
\label{ssec:concl-general}

This subsection will give some generic conclusions on the work
conducted and the environment in which is was conducted. When I
started this task, it was only supposed to be a small part of my
complete graduation. Due to various factors, of which the two most
important the difficulty of the scheduler source and the environment
in which I conducted part of my thesis, my large task list gradually
shrank to the two main topics as discussed in this thesis. Apart from
these two projects, also various other small projects related to the
MOVE project and the PcomP processor at NEC C\&CRL were undertaken, 
but they fall outside the scope of this thesis

The scheduler source is a fairly large code base, contributed to by
various developers, who use their own coding-style and even
language. Also, the documentation on the source is not complete and in 
some cases even ambiguous. This 
results in the fact that a minor adaptation in one part of the source
can result in revealing a bug or just misunderstanding of the API in a 
completely different part of the source. This makes bug hunting very
cumbersome. Also, because of the obsolete versions of the GNU
front-end, the front-end is very hard to adapt.  This all results in
the fact that the estimated time on bug-hunting is about 50\% of the
time spent on the project.


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Recommendations}
\label{sec:recomm}

This section will give recommendations on future work on the projects
discussed in this thesis. Subsection~\ref{ssec:rec-end} will give some 
recommendations on the endianness work and
subsection~\ref{ssec:rec-limm} will present some recommendations on
the long immediates implementation.

\subsection{Endianness}
\label{ssec:rec-end}

A few observations with respect to the endianness port can be made:

\begin{itemize}
\item The front-end tools are quite obsolete. The used version of the
assembler, linker and bintools is version 1.38, which was current in
1993. The GNU project has developed much better, and most important,
much better portable tools since then. The newest versions use a
common library, {\tt libbfd}, that takes care of all binary-format
specific tasks. This means that the assembler, linker and bintools
itself need very little changing. {\tt libbfd} is a very easily
portable library, constructed with the easy port to a new architecture 
in mind. Also changing the endianness of a target would have been much 
easier with this library. It is recommended that in the future a newer 
version of the GNU tools are used, in order to be better prepared for
future modifications. The reason that this was not undertaken in this
project was that due to time constraints, a quicker, albeit less
long-term, solution was chosen.
\item All intermediate forms of the front-end are binary. Since the
back-end needs to parse this binary back again into an internal
format, it might be advisable to look into the possibilities of a
textual representation of all intermediate steps. This eliminates a
lot of endianness problems, and simplifies the reader of the
back-end. Also intermediate steps can be visually inspected much
easier this way. Drawbacks might include a larger size and possible
parsing complexity, but I do recommend that this option is taken into
consideration. 
\end{itemize}



\subsection{Long Immediates}
\label{ssec:rec-limm}

The work done on the long immediates represent a complete
implementation for scheduling long immediates in the MOVE
framework. However, there is always room for more
improvements. Various ideas for future work will be presented,
together with a judgment on the feasibility and usefulness of those
ideas. These ideas are already explained in detail in
section~\ref{sec:future}, together will outlines on how to implement
these.  

\paragraph*{Exploration}
Exploration means trying different machine descriptions until an
optimal architecture is found. Optimal is here defined as a balance
between costs (die area) and performance (execution time). Long
Immediate Encoding could be another parameter that is automatically
exploited.. Since the design of long immediates in MOVE is so
extremely flexible, an implementation of long immediates in {\tt
explore} should be designed very carefully. It is recommended that the
{\tt explore} tool is adapted to take Long Immediates into account.

\paragraph*{Immediate sharing}
Immediate sharing means re-using the immediate write. Tests have shown 
that the possibilities for immediate sharing are very limited in normal 
applications. The framework as implemented is however almost ready to
deploy immediate sharing, all data structures and helper functions
are in place. However, the complexity of the scheduler makes it
unlikely that the scheduler will produce correct code immediately. A
decision should be made whether this immediate sharing is desired,
based on a review of the performance gain and a study how hard it will 
be to enable immediate sharing correctly.


\paragraph*{Region scheduling of immediates}
Region scheduling, or importing of immediates means moving and copying
an immediate write to predecessor blocks if an immediate write cannot
be scheduled in its home basic block. The same logic as in the
previous paragraph goes here too: A fair part of the code and
algorithms needed to implement this in the scheduler is already
present. However, tests show that possibilities for importing are
relatively low compared to the work that will be needed to achieve a
correct implementation. History has learned that the scheduler source 
is full of undocumented side effects, and care should be taken to not
underestimate the time needed to get a bug-free implementation.
