Rainbow Electronics AT89C2051 - Manual (Page 3)

Microcontroller
5-49
The greatest overhead burden that I
2
C imposes involves
the transfer of addressing information. For every random
read or write, a 16-bit address must be transmitted along
with the extra overhead necessary to coordinate bus con-
trol for both the addressing phase and the data manipula-
tion phase. Under such conditions, actual data movement
could be swamped by the requisite overhead resulting in
unacceptable performance degradation. Fortunately, I
2
C
provides a means of eliminating much of this wasteful activ-
ity.
The AT24C64, like all other I
2
C memory devices, contains
an internal auto-increment address generator. Using this
feature, once addressability is established, data can be
continually streamed in a sequential fashion. As each byte
is read and acknowledged the internal address generator
increments in preparation for the next byte transfer. The
AT24C64 sets the maximum speed limit at 400 kHz but I
2
C
does not impose a lower limit. Effectively, the minimum fre-
quency can drop all the way to DC. As a result, it’s accept-
able to suspend a sequential transfer for as long as neces-
sary.
Utilizing these features, communications can be sped up
considerably. The ramifications are particularly significant
when the memory is used to store an executable program.
For example, once an address is written into the AT24C64,
data can be fetched in a continual stream until the program
branches or, if multiple AT24C64’s are used, until it
becomes necessary to cross into the next chip. At these
points it’s necessary to explicitly reload the internal address
generator. Normally, however, the majority of the accesses
will be sequential, resulting in greatly reduced overhead.
Processor Simulators and Language
Interpreters
It’s important to note the distinction between language spe-
cific interpreters that implement a defined language such
as BASIC, and a processor simulator that interprets a low
level binary instruction set. A tokenized BASIC interpreter,
while quite efficient in executing the commands that are
explicitly implemented as part of the language, is strictly
confined to what the language supports. The inherent effi-
ciency of an interpreted language comes at the expense of
flexibility.
In contrast, a processor simulator, that deals with a true
binary instruction set, enjoys total freedom in combining
these basic op codes into larger functional entities in
almost limitless permutations. Just like a real processor, a
simulated processor can utilize its instruction set for stan-
dard and custom C library functions, floating point libraries,
device drivers, etc.
The Virtual Machine — An Imaginary
Processor
The processor to be described is imaginary in the sense
that its architecture and instruction set are original and
unique. Realize, however, that this is not just a toy or an
intellectual diversion—from an implementation standpoint it
is quite real. The fundamental concept has been success-
fully ported to a variety of processor architectures. A ver-
sion exists that runs on a personal computer that is suitable
for demonstration and development purposes. The most
promising small-system port has been to the AT89C2051
due to the microcontroller’s standard processing core and
integrated peripheral set. The basic 8K Virtual Machine is
schematically depicted in Figure 1. The circuit’s simplicity
reveals that this is primarily a software implementation—
the definitive soft machine.
This imaginary processor, the product of Dunfield Develop-
ment Systems, has served in various applications providing
reliable solutions to real world problems where a standard
configuration was not necessary, optimal, or practical. That
this Virtual Machine also goes by the name “C-FLEA”
affirms its optimization for efficiently rendering the output of
a C language code generator.
The prime currency of a processor is time. Viewed in this
context, the expense of complexity can prove unacceptably
burdensome. Taking this into consideration, the Virtual
Machine, based on a simple 16-bit architecture that incor-
porates only four registers, is the epitome of simplicity. This
register set comprises an accumulator, index register,
stack pointer, and program counter. Appendix A provides
detailed information about the Virtual Machine architecture
and instruction set. Refer to Table 1 for a description of the
fundamental resource set.
Although the Virtual Machine performs all operations to 16-
bit precision, the needs of many embedded systems
resolve to 8 bits. To facilitate working with this common
denominator, the Virtual Machine stores data in little endian
format (low byte first) which facilitates the use of a given
variable’s base address to refer to either an 8-bit or 16-bit
quantity. Interestingly, the architecture provides no user
accessible flags. When invoking a compare instruction,
internal flags persist only long enough to accommodate the
ensuing branch instruction or the intervening compare
modifiers (which are described later).
This spartan register set is made workable by the inclusion
of a variety of addressing modes that excel at the types of
stack manipulations that are central to the canonical C
implementation. The Virtual Machine’s memory access
instructions, detailed in Table 2, include the following
addressing modes: immediate (8 or 16 bit), direct, indirect
through index register (with or without offset), indirect
through stack with offset, top of stack, and indirect through
top of stack (remove or leave value on stack).