Mark Klein wrote:
> On 3 Mar 2003 at 13:58, Gavin Scott wrote:
>
>
>>One can argue whether "Emulator" is the correct technical term for
>>this ("Simulator" is probably more correct from a dictionary point of
>>view) but the world seems to have generally settled on the use of
>>"Emulator" for this type of thing.
>
>
> I have been having discussions about "Platform Emulation" and
> "Platform Simulation" with some people. I view them differently, so
> I'd like to introduce the latter definition, for sake of argument.
>
> I agree that "Emulation" should be what we've been talking about when
> we discuss a "binary" solution. In other words, we can pick up our
> binaries from our existing 3000 hardware and run them unchanged under
> the "Emulator".
<snip>

The terminology in this area becomes very subjective very quickly.

Here at Strobe, we don't like to refer to our products as emulators at
all, because in some parts of the industry the term is held in
disregard (military customers seem especially sensitized to the term).
  The best term I have come up with, other than simply "the CPU", is
"the instruction execution engine".  Because we have traditionally
made boards that live in a host machine but process the opcodes of the
target machine *in hardware*, we simply view them as the newest model
of that particular computer line.  The reason that we don't call our
Kestrel an "HP1000 Model 9990" has much more to do with legal rights
(HP has them, we don't) than it does with the faithfulness with which
we execute the instruction set.  A Kestrel is an emulator of an
F-Series in just the same way that the F-Series was itself an emulator
of the HP2116 that preceeded it.  By the same logic, an MPE-IX machine
is an emulator of the Series-70 that preceeded it and the Series-III
before that...

If someone wishes to make the distinction that the future generation
of MPE boxes might be "only software", I would remind them that ALL
the classic MPE boxes were microcoded.  Thats a fancy term for
"software running on a machine you don't get to touch".  Of course the
PA-RISC boxes used a software emulator to execute those portions of
the code which were not recompiled into native mode.

At some level, it is all an emulation ;)

Where we do use the term emulator here at Strobe is in our "I/O device
emulations".  A device emulation has the task of "looking like" some
physical I/O interface card or subsystem.  The host device may
resemble the target device in only the most superficial ways (its a
disk, it has storage blocks, it writes them and reads them).  The
device emulation must ensure that the CPU (instruction execution
engine) sees exactly what it is expecting to see and all operations
produce the same results that they would have in the native
environment.  The device emulation is purely software that translates
from the low level I/O instructions that are presented by the
instruction stream into the host I/O calls that work with the host
O.S. and hardware, while maintaing a state machine that parallels the
legacy hardware.

As I have said in other posts to this list, that is where the real
hard work lies.  Can anyone out there present an assembly language
sequence which can display "Hello World" on the line printer *without*
MPE loaded?  Just exactly what memory location should I poke the value
0x48 into to make the "H" appear?  What memory location should I read
to check status to see if I can send the 0x65 without overruning the
channel when I want to make the "e" appear?  Or maybe it doen't work
that way at all, perhaps I put the entire string in some location and
then send the address of that string to some memory location and then
wait for an interrupt (which bit of which register controls that?)
instead.  On the HP1000, customers attended classes where they were
taught how to write I/O drivers and the interface card manuals
included detailed instructions telling how to make them do whatever
they did.  I have not seen this level of detail on MPE since 1975, so
there is much that must be discovered.

My optimism is tempered by my ignorance.  Luckily, ingnorance is
considered to be curable.

--
Alan Tibbetts           Strobe Data, Inc.
Project Manager         8405 165th Ave. NE
425 861 4940            Redmond WA
[log in to unmask]      98052-3913