The
Computational Model
Operators
and Parameters
The
ReAl architecture supports the exploitation of an arbitrary
number of arbitrary resources. Fig. 1 illustrates how
a single resource is be used according to the ReAl computational
model. In the example, the following steps are executed:
- Parameters (operands) are fetched from memory
and passed to the resource.
- The operation is executed (by activating the
hardware or by invoking an appropriate software routine (emulation)).
- The result is stored in the memory (in other
words, assigned to the corresponding variable).

Fig.
1 How a single resource is used
– the basic computational model.
When
only one resource is considered, especially one that has only
a few parameters and executes only well-known basic operations,
there is virtually no difference to conventional computer architectures
(fig. 2). It is merely the question whether the consecutive
processing steps are controlled implicitly by the control unit
(instruction sequencer) or explicitly by appropriate encoded
commands. In this respect the ReAl architecture bears
some resemblance to the principles of vertical microprogram
control. The peculiar ReAl benefits however will come into effect
when more than one resource is exploited and when the ReAl principles
of operation are applied to the program as a whole.
Concatenation
Resources
can be combined to complex arrangements. Such a configuration
corresponds to the data flow diagram of the respective processing
operations (fig. 3). The ReAl computational model
implies provisions for connecting resources according to data
flow diagrams and for disconnecting again these connections.
In the following, such connections will be referred to as concatenations.

Fig.
2 For comparison: instruction execution in a
conventional processor.

Fig.
3 A
basic example of resources combined according to a data
flow diagram: three resources have been concatenated to calculate
(A + B) • (C + D).
The
basic ReAl Operators
In
a ReAl machine, the processing steps are controlled by stored
instructions. The abstract (machine-independent) instructions
are referred to as operators. There are at least eight basic
types:
1.
Select resources: s-operator.
2.
Establish concatenations between
resources: c-operator.
3.
Feed resources with operands from
memory (parameter passing): p-operator.
4.
Initiate the information processing
operations: y-operator (yield).
5.
Move data between resources: l-operator
(link).
6.
Assign results (to variables in
memory) : a-operator.
7.
Disconnect concatenations: d-operator.
8.
Return resources to the resource
pool: r-operator.
Some
basic variants:
- The
concatenation is not supported at all. The operator
types 2 and 7 are obsolete. The parameter transport
is to be done exclusively with p-operators, l-operators
and a-operators, the operation initiation exclusively
with y-operators.
- Not
all resources support an unlimited concatenation. When
this is the case, arbitrary data flow schemes cannot
be supported. In some cases, the concatenation provisions
are not usable.
- The
input concatenation is not supported. The concatenation
can only be used for moving parameters between resources,
but not for initiation of operations. Hence all operations
are to be initiated by y-operators.
- The
input concatenation is supported. In this case, it
is possible to automatically initiate the respective operations
without a y-operator. Such a resource begins – if
set up appropriately – with the execution of the operation
when all operands are valid, no matter in which way they
are supplied (p-operator, l-operator or concatenation).
Parameter
passing
The
data with which the resources work are generally referred to
as “parameters”. Input parameters are also referred to
as operands; output parameters are referred to as results. Thre
are three types of parameters:
- Inputs
(operands; type IN).
- Outputs
(results; type OUT).
- Combined
inputs and outputs (type INOUT).
Parameters
are passed in general by value. If this is not easily
possible, additional resources (for example, addressing respources)
must be provided in order to fetch and move the values.
Additional
operators
In
practice, additional operations are to be initiated and additional
information is to be passed to, for example, for supporting
compilers, for system administration and the like. In
order to be able to provide such supporting functions in a way
consistent with the basic principles of operation, some supplemental
operators are introduced:
1.
Hints: h-operator.
2.
Meta-language support: m-operator.
3.
Administrative and auxiliary functions:
u-operator (utility).
Denotation
of ReAl Program Operations
ReAl
programs are essentially sequences of operators. ReAl program
operations can be represented as follows:
- Colloquial
(for example, in a cookbook-like fashion ("take a multiplier
and concatenate it to a comparator" and so on). This
requires no special conventions but is copious and not always
free of ambiguities.
- ReAl
text code. Text codes are concise formalized denotations
based on simple character strings. They are used when a
machine-independent and human-readable representation is
required. Typical examples are documentation, debugging,
program development and compiling.
- ReAl
byte code. Byte codes are variable-length binary encodings.
A ReAl program in byte code is essentially a string of bytes.
Such codes are used when a machine-independent, but
compact representation is required. Typical examples are
compiling and emulation.
- ReAl
machine codes. Machine codes can be laid out according to
fixed-length or variable-length formats. Simple fixed-length
formats resemble the well-known RISC instructions (an opcode
followed by some parameter fields containing ordinal numbers
or addresses). Alternate formats may contain many fields
to control many resources in parallel, resembling VLIW instructions
or horizontal microinstructions.
In
the following descriptions a simple text code will be employed.
The basic syntax:
- Designators
(of resources, resource types and parameters) may
be ordinal numbers or symbolic names. The primary designation
is by consecutive ordinal numbers (1st, 2nd etc. resource,
1st, 2nd etc. parameter and so on). To those ordinal numbers,
symbolic names can be assigned.
- Parameters
are enumerated consecutively: first the inputs, then the
inputs and outputs, then the outputs (fig. 4). Each parameter
is designated by its ordinal number.
- Resources
are enumerated consecutively. Each resource is designated
by its ordinal number. The ordinal numbers are assigned
according to the sequence of s-operators. The assigned
ordinal numbers remain valid even when intermediately resources
with lower numbers have been returned (r-operator).
- Assignment
of a symbolic name to an ordinal number (more details see
below):
ordinal
number : symbolic name.
- Spaces
can be inserted or omitted as needed. A line feed does not
matter.
- The
assignment symbol is := (the colon designates the destination
side).
- Parameter
passing is denoted by => (the arrow symbolizes the direction).
- The
comment symbol is -- (refer to Ada and VHDL).
- Each
operator is designated by a particular mnemonic character:
operator_
name = s | c | p | y | l | a | d | r | h | m.
- An
operator within a program: operator_name (argument_list).
- A
parameter (operand or result) of a particular resource will
be represented as follows:
resource
. parameter.
- Designation
of variants of the operators: by additional abbrevaitions
that are separated by an underscore (for example, s_a; p_imm
or u_rs2).

Fig.
4 Resources with enumerated parameters.
Assignment
of symbolic names:
- Resource
types: Symbolic names are usually predefined in the resource
type table or in the reference manual of the particular
ReAl machine. Those names can be overloaded by appropriate
u-operators:
Assign
resource type name: u_tn.
u_tn
(ordinal number : symbolic name).
Rename
resource type: u_trn.
u_trn
(previous symbolic name : new symbolic name).
- Parameters:
Symbolic names are usually predefined in the resource type
table or in the reference manual of the particular ReAl
machine. Those names can be overloaded by appropriate u-operators:
Assign
parameter name: u_pn.
u_pn
(ordinal number : symbolic name).
Rename
parameter: u_rrn.
u_prn
(previous symbolic name : new symbolic name).
- Resources:
Symbolic names can be assigned during invocation of the
desired resource type (s-operator) or by appropriate u-operators:
Assignment
in the parameter string of the s-operator: resource type
: symbolic name.
Assign
resource name: u_rn.
u_rn
(ordinal number : symbolic name).
Rename
resource: u_rrn.
u_rrn
(previous symbolic name : new symbolic name).
Basic
Operators
1.
Select resources: s-operator
s
(list of resource type identifiers)
s
(1st resource type, 2nd resource type an so on)
The
s-operator is used to request resources of certain types out
of the resource pool.
The
effect of a s-operator depends on the requested resources as
well as of the kind of the underlying hardware:
An
appropriate hardware resource (in other words, a function unit
(like an ALU)) is reserved, initialized and assigned.
Appropriate
memory areas are reserved, initialized, and assigned. Optionally,
the respectively required control information is loaded (programs,
microprograms, net lists, Boolean equations and the like).
The
requested resource is built from other resources (recursion).
An
appropriate hardware structure is generated, for example,
by programming cells and connections on a programmable integrated
circuit.
Initializing
a resource means to set up literals and initial values,
to adjust the data width, to load control information (like
microprograms) and so on. Assigning a resource means to incorporate
it into the administration of the selected resources so that
it can be accessed by subsequent operators under ordinal number
or by addressing.
Resource
type identifiers
For
conventional (generic) resources, the resource type identifier
is the appropriate type designator (as given, for example, in
the particular reference manual). Special resources are designated
by their particular symbolic name. Generally, Internet addresses
and the like can also be used as identifiers.
Enumeration
of resources
The
requested resources are enumerated consecutively. Subsequent
operators then refer to the selected resources by those ordinal
numbers (or by the assigned symbolic names).
2.
Establish concatenations between resources: c-operator
c
(list of concatenations)
c
(1st source resource . 1st result => 1st destination resources
. 1st parameter, 2nd source resource . 2nd result => 2nd
destination resource . 2nd parameter and so on)
Concatenation
means to connect an output (result parameter) of the source
resource with an input (operand parameter) of the destination
resource.
The
c-operator loads concatenation control information (like address
pointers) into the resources). In some implementations the operator
will initiate the setup or programming of appropriate physical
connections (for example, within a switch fabric or an FPGA).
If concatenation is exploited to the extreme, the concatenated
resources constitute a structure which corresponds to the dataflow
graph of the application problem.
Input
concatenation
When
supported appropriately, it is possible to concatenate inputs
with one another (input concatenation). Such a concatenation
corresponds to connecting corresponding inputs in parallel.
Application: for supplying simultaneously parameters to
several resources.
3.
Feed
resources with operands (parameter passing): p-operator
p
(source-to-destination list). Source are variables in
system memory or the like, destinations are parameters of resources.
p
(1st variable => resource . parameter, 2nd variable
=> resource . parameter and so on)
The
p-operator moves the specified variables (for example, from
system memory or an I/O address space) into the specified operand
parameter positions of the specified resources. The variables
are designated by names, ordinal numbers or addresses.
In
resources that support concatenation appropriately, p-operators
can also initiate the execution of operations (processing begins
when all operands are valid).
4.
Initiate the information processing
operations: y-operator
y
(list of resources)
y
(1st resource, 2nd resource and so on)
A
y-operator initiates the execution of operations in the specified
resources. What the respective resources will do, depends on
directly from the type of resource (when it can perform only
a single function) or on parameters (function codes) that have
to be set beforehand (for example, by means of s-operators or
p-operators).
An
alternative method of operation initiation – without a y-operator
– can be applied when the resource supports concatenation. The
execution of an operation will be initiated if all required
operands are valid. Valid operands can be supplied by means
of p-operators or l-operators or by concatenation.
Contrary
to conventional instruction sets, the selection of the operation
to be executed (s-operator) has been separated from the initiation
of the operation (y-operator or concatenation). Hence the resources
know in advance for which purpose the operands are destined.
The initiator code (within y-operators) is typically shorter
than a conventional operation code. This avoids instruction
traffic during execution and can be an advantage if more than
one function is to be initiated (appropriately formatted y-operators
can initiate more operations simultaneously than conventional
instructions of same length).
5.
Move
data between resources: l-operator
l
(source-to-destination list). Sources and destionations are
parameters of resources.
l
(1st source resource . 1st result => 1st destination resource
. 1st parameter, 2nd source resource . 2nd result => 2nd
destination resource . 2nd parameter and so on)
The
l-operator moves parameters between the specified resources
(from the output (result parameter) of the source resource to
the input (operand parameter) of the destination resource, respectively).
In
resources that support concatenation appropriately, l-operators
can also initiate the execution of operations (processing begins
when all operands are valid).
6. Assign
results: a-operator
a
(source-to-destination list). Sources are parameters of
resources, destinations are variables in system
memory or the like.
a
(1st resource . 1st result => 1st result variable, 2nd resource
. 2nd result =>2nd result variable and so on)
The
a-operator moves the contents of the specified result parameter
positions of the specified resources to the specified variables
(for example, in system memory or in an I/O address space).
The variables are designated by names, ordinal numbers
or addresses.
7.
Disconnect
concatenations: d-operator
d
(list of concatenations)
d
(1st source resource . 1st result => 1st destination resource
. 1st parameter, 2nd source resource . 2nd result =>
2nd destination resource . 2nd parameter and so on)
The
d-operator disconnects existing concatenations. In some implementations
(for example, in FPGAs) it can cause the corresponding physical
connections to be changed or cut off (by reprogramming). Disconnected
resources can be used separately or can be concatenated again.
8. Return
resources to the resource pool: r-operator
r
(resource list)
r
(1st resource, 2nd resource and so on)
The
specified resources are returned to the resource pool. They
are therefore available to be used for other processing tasks.
Basic
Examples
The
following example illustrates how a programming intention can
be implemented.
The
programming intention: to compute X := (A + B) • (C +
D).
Available
resource types: ADD, MULT.
Fig.
5 illustrates the corresponding resource configuration comprising
two adders (ADD) and a multiplier (MULT). The ordinal numbers
of the resources: first adder = 1, second adder = 2, multiplier
= 3. The ordinal numbers of the parameters of a resource:
inputs (operands) = 1 and 2, result = 3.

Fig.
5 A
resource configuration to compute X := (A + B) • (C + D).
The
notation at full length (each step individually):
s
(ADD)
s
(ADD)
s
(MULT)
p
(A => 1.1)
p
(B => 1.2)
p
(C => 2.1)
p
(D => 2.2)
y
(1)
y
(2)
l
(1.3) => 3.1)
l
(2.3 => 3.2)
r
(1,2)
y
(3)
a
(3.3 => X)
r
(3)
An
abbreviated notation:
s
(ADD, ADD, MULT)
p
(A => 1.1, B => 1.2, C => 2.1, D => 2.2)
y
(1, 2)
l
(1.3 => 3.1, 2.3 => 3.2)
r
(1, 2)
y
(3)
a
(3.3 => X)
r
(3)
The
resources connected according to the data flow (concatenation;
refer to fig. 3):
s
(ADD, ADD, MULT)
c
(1.3 => 3.1, 2.3 => 3.2)
p
(A => 1.1, B => 1.2, C => 2.1, D => 2.2)
y
(1, 2, 3)
-- begin of processing in the concatenated resources
a
(3.3 => X)
r
(1, 2, 3)
The
y-operator is not needed when the resources support an appropriate
advanced concatenation mode.
Some
additional operators
1.
Select a resource and assign a
particular ordinal number: s_a-operator
s_a
(list of pairs resource type identifier => resource
ordinal)
s_a
(1st resource type => 1st resource ordinal, 2nd resource
type => 2nd resource ordinal and so on)
This
variant of the s-operators assigns particular ordinal numbers
to the requested resources. Depending on the implementation,
similar operators can be provided to assign addresses
in a resource address space instead of the ordinal numbers.
2.
Load
immediate values (literals) into resources: p_imm-operator
p_imm
(list of pairs literal => destination). The destinations
are parameters of resources.
p
(1st literal => resource . parameter, 2nd literal =>
resource . parameter and so on)
The
p_imm-operator moves immediate values (literals) into the specified
operand parameter positions of the specified resources.
In
resources that support concatenation appropriately, p_imm-operators
can also initiate the execution of operations (processing begins
when all operands are valid).
3.
Initiate selected functions: y_f-operator
y_f
(list of pairs resource . function code)
y_f
(1st resource . 1st function code, 2nd resource . 2nd function
code and so on)
A
y_f-operator initiates the specified functions in the specified
resources.
This
variant contradicts the principle of encoding in the operators
only the most basic processing steps but not concrete machine
operations. It is some kind of stopgap minimalist solution
(suitable, for example, for small FPGAs, microcontrollers and
the like).
4.
Provide hints to support speculative
activities: h-operator
Hints
(h-operators) can cause variables or program pieces to be loaded
speculatively into cache memories so that, when required, they
are already available). Additional h-operators can be
provided in order to indicate future demand in regard to certain
resource types or certain configurations of resources. Such
hints can be used, for example, to select such resources out
of the resource pool which are, in regard to a subsequent concatenation,
conveniently located on the integrated circuit.
5.
Provide information for compiling
and other activities of program generation: m-operator
Meta-language
operators (m-operators) concern the setup of resource configurations,
the conditional execution of ReAl programs and the like. Such
operators are similar to the pre-processor and compiler directives
of conventional programming languages. However, they can
become active not only at compile time but also at run time.
A typical application: as a function of which resource types
are available, one of several alternative branches of
a ReAl program is selected in order to execute a certain programming
task. Conventional conditional branches depend on processing
results, operand values and so on. Meta-language caused
branching depends, for example, on the type and number of available
resources. The m-operators can access and change the contents
of the table structures of resource administration.
6.
Auxiliary and aministrative functions:
u-operator
All
those functions that are required during program execution but
cannot be encoded with operators s, c, p, y, l, a, d, r, h,
m are encoded with u-operators (in other words, u-operators
are some kind of stopgap provision).
Implementation
of h-, m- and u-operators
The
functions that are encoded with h-, m-, and u-operators can
be provided by means that are outside of the resource pool.
This can be, for example, a conventional general-purpose
computer that administers and controls the pool of processing
resources. Appropriate functional units are generally
referred to as platforms.
Alternatively,
it is possible to specifically provide for many of these functions
additional resources or to configure, based on already present
resources, corresponding resource arrangements ad hoc, for example,
resources that fill speculatively cache memories, reserve other
resources, or administer resource tables. Basically, the
platform outside of the resource pool can be restricted to the
most elementary functions of instruction fetch, initialization
and the like. All other functions can be implemented by basic
ReAl operators employing a sufficiently equipped resource pool.
Therefore, a more precise description of the h- and m-operators
is not required here. Some u-operators will be explained in
more detail when necessary.
Operators
and Instructions
- Operators
describe the basic steps of information processing. Machine-independent
ReAl programs are sequences of operators. To be stored and executed
on ReAl machines, operators have to be encoded. There
are several alternatives:
- One
machine instruction corresponds to one operator.
- One
operator requires more than one machine instruction. An instruction
encodes only an elementary processing step (for example, loading
of a parameter address). The functions of the ReAl operators
are emulated with sequences of corresponding instructions (resembling
a conventional vertical microprogram control).
- One
instruction contains more than one operator (resembling the
conventional VLIW instructions).
- Control
words that contain individual control bits as well as literal
fields, address fields, and control fields. Such control words
serve primarily for supplying with parameters, activating
and so on a large number of resources at once (resembling a
conventional horizontal microprogram control).
- Instructions
that are similar to the machine instructions of conventional
architectures.
- The
operators are converted into sequences of conventional machine
instructions or corresponding function calls (for example, by
means of compiling).
ReAl
and Conventional Programming Languages
Fundamentally,
ReAl programs can be likened to manufacturing or machining instructions)
– ReAl programming means just to plan ahead. Which manufacturing
steps are to be executed? Which tools and machines are necessary?
Which part has to be supplied to which machine in the course
of time? No engineer would begin designing cars, ships
and so on writing down instructions of this kind. Analogously,
a programmer will not use a ReAl text code for jotting down
his programming ideas.
Instead,
ReAl programs will be generated automatically from source
programs written in higher-level languages. Machine-independent
ReAl codes can be seen as intermediate languages, similar to
the well-known Java byte code (table 1). However, the goal
is not code compactness but to describe precisely the inherent
parallelism and essential intricacies of program operation.
In this respect, ReAl may be better compared to Postscript than
to Java.
Some
variants related to compiling and program execution:
- Programs
written in a conventional programming language will be compiled
into machine-independent ReAl code.
- Programs
written in a new ("ReAl-aware") programming language
will be compiled into machine-independent ReAl code.
- The
machine-independent ReAl code will be executed by an appropriate
emulator.
- The
machine-independent ReAl code will be compiled into the machine
code of a conventional processor (in other words, the ReAl code
is used merely to detect the inherent parallelism).
- The
machine-independent ReAl code will be compiled into ReAl machine
code.
Java, JVM |
ReAl |
- Code compactness (bytecode)
- Developed for small programs
(applets)
- Executable on thin machines
- Programs to be downloaded via
internet
- JVM is a conventional stack
machine, hence its operations are
inherently sequential
- JVM bytecode describes one
operation at on time, hence inherent
parallelism is to be detected during
runtime
|
- To make best possible use of hardware
- Developed for large and computing-intensive programs
(graphics, equation solving, simulation, data bases, neural
networks, AI)
- There will always be enough hardware. Memory capacity
and code size are irrelevant
- Executable on machines which can be built with future IC
technology (dozens or even hundreds of operation units on
one integrated circuit)
- ReAl code describes completely the inherent parallelism of
program operation
- Creation of virtual special processors which correspond to
the dataflow graph of the application problem
- Inherent parallelism will be detected not during runtime but
in statu nascendi (i.e., by examination of the programming
intentions)
- A sufficiently standardized ReAl instruction set is a unified
machine language, which can describe hardware as well as
software
|
Table
1 Java Virtual Machine (JVM) vs. ReAl.
|