\chapter{Introduction}
\label{cha:introduction}
\label{sec:background}

This chapter gives a short introduction to the various topics covered
in this thesis. 

%First, the background to which my work was carried out 
%will be explained in section~\ref{sec:background} and a motivation for 
%the specific problems covered will be discussed in
%section~\ref{sec:motivation} After that, in
%section~\ref{sec:overview} an overview on the rest of the thesis will
%be given.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

%\section{Background}

At the laboratory of Computer Engineering of the Department of
Electrical Engineering, Delft University of Technology, research has
been done in automating the design process of application specific
processors (ASPs). ASPs represent a huge part of the microprocessor
market, as they are used in increasingly popular embedded systems.

One of the largest part of the costs of an ASP is its design time. To
shorten this design cycle, this laboratory has been developing an
automated design framework based on the {\em Transport Triggered
Architecture} paradigm.  The concepts behind TTAs were developed in
the same research group, and proved themselves to be especially suited
for the ASP synthesis. For an in depth description of the move
framework, please read chapter~\ref{cha:move}.

Several for-profit companies have been interested to take the Move
framework principles and use them in their own products. One of them
is NEC Computer and Communications Research Labs (CCRL) in Princeton,
New Jersey, USA~\footnote{see http://www.ccrl.nj.nec.com/}, later spun
off into the independent company Eulix Networks. While developing a
programmable communications processor, they needed a core that was
both flexible in its interface and functionality while having a short
design cycle. The MOVE framework was chosen to implement this
core. The requirements as posed upon the MOVE framework by the
communications processors specifications included, amongst others, a
little-endian version of the MOVE core, support for long immediates,
support for some special function units (SFUs) attached to the MOVE
core, support for 64bit loads and stores, support for global
registers, and support for an interface to the co-design simulator of
the processor.

In September 1999, I was asked by my professor, dr. H. Corporaal, to
join the development group in New Jersey to work primarily on two of
these issues, namely the support for long immediates and the support
for endianness independence. I also did some work on other problems
related to the integration of the MOVE core into the communications
processor, but they will not be discussed here as they fall outside
the scope of my master's thesis.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%\section{Motivation}
%\label{sec:motivation}

%In this section, the motivation for the two problems stated above will 
%be addressed.

\section{Endianness independence}
The communications processor, as developed by Eulix Networks, deploys
several on-core traffic control units as well as some busses, e.g. a
standard PCI bus for external host-communications. Since these were
all developed as little-endian modules, it was natural for the MOVE
core to be little-endian, too. Traditionally, MOVE has been a
big-endian target, developed and simulated on big-endian hosts, like
HP's HPPA and Sun's Sparc architectures. Lately, development in the
research laboratory has been shifted towards more common, cheaper, x86 
platforms, running the Linux operating system. The x86 is a
little-endian platform.

All these factors lead to the conclusion that the traditionally
big-endian-host/big-endian-target architecture of MOVE needed to be
extended to handle all four permutations of host and target endianness.

\section{Long Immediates}
Traditionally, MOVE has been primarily a research concept, with few
actual realized hardware prototypes. As such, the limitation that the
width of an immediate in bits needed to be shorter than the
(fixed-width) instruction width of an instruction slot, could be
easily overcome, since the simulator didn't need to work on the actual 
bits of the binary, but on a symbolic representation of the scheduled
program in memory.

In the cases where a chip was actually realized, short term solutions
were devised. One of them was to use a two-step stage, where an
instruction containing an immediate was always followed by an
instruction slot that did not contain an instruction but the value of
the immediate. The program counter was incremented by two instead of
one in this case.\footnote{This solution was implemented in the
MicroMove~\cite{umove} processor by TNO-FEL, The Hague,
Netherlands}. This was a good solution since the scheduling freedom
was low anyway, due to the fact this particular MOVE instance had only
1 bus, but a bad one if the MOVE architecture would define multiple
busses, since then it would be more advisable to schedule them into
empty slots that are inherently present in VLIW scheduled instruction
words.

Another solution was to add a dedicated immediate field at the end of
the VLIW instruction word, that could never contain an instruction but 
only an immediate. Downside of this solution is that an instruction
word would always contain one or more immediate fields, and that in
case there was no instruction with an immediate present, bits would be 
wasted, which is a significant factor when it comes to low-cost
embedded processors.

Above observations led to the conclusion that a new way to schedule
immediates needed to be implemented. An implementation that would not
waste bits but would try to schedule an immediate in unused
instruction in the instruction word stream, thus minimizing the code size.





%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
   
\section{Overview of the rest of the thesis}
\label{sec:overview}
First, chapter~\ref{cha:move} will describe the Move project, in order
to have a good understanding of the principles of the Move framework.

The remaining of this thesis will further address the main two topics
of this thesis.

Chapter~\ref{cha:endianness-overview} will
address the ideas and difficulties behind endianness
of both host-endianness dependencies and target-endianness
dependencies. Chapter~\ref{cha:endianness-impl} will explain how these
problems were addressed in making the Move framework both
host-endianness as well as target-endianness independent.

Chapter~\ref{cha:limm-overview} will explain the rationale behind long
immediates in the Move framework. Chapter~\ref{cha:limm-impl} will
address the implementation of long immediate support in the Move
framework. Chapter~\ref{cha:limm-review} will review these
adaptations, and a quantitative and qualitative analysis will be given,
as well as a comparison with a functionally similar approach to long
immediates encoding and implementation in a different research group.

Finally, chapter~\ref{cha:conclusions} will draw conclusions on the
results and will give some recommendations for future work on this
subject.

