Chris wrote....
Can anyone on the list tell me the current status of
Jay West's hpemu
project?
Well, sort of. I haven't found enough of the missing parts I need (called
"round-tuit's") to finish off the hpemu project ;) It has been in that state
for a long time. However, I can assure you it is not dead, someday I will
definitely get around to finishing it off.
Since I haven't touched it in so long I don't remember the exact state of
where I left it. As I recall, there were two things left to finish - the
doubleword floating point multiply/divide (FMP/FDV) instructions, and a few
more peripheral devices. I just don't get binary floating point math, I have
to think way too hard for it. Often much more complex things in the coding I
can grasp with ease, but there's something about binary floating point math
that joest doesn't click with me. I can do it, but it takes eons. I know
there are easy ways to accomplish this, like mapping the HP format to IEEE,
doing the operations, then converting back... but you lose the bug-for-bug
identical nature of what I've been able to adhere to so far. As a result, I
spend lots of time pouring over microcode and diagnostic source to make
painfully sure my code produces all possible results identically. The
diagnostics are the definitive test, and I can say with pride that HPEMU
currently passes all standard HP diagnostics except the unimplemented
FMP/FDV stuff. I can even pass the HP power-fail auto-restart test and the
memory parity error test. How's THAT for going to extremes to code in
exactly identical behaviour?
One of the recurring themes in my code is that I do not do things
necessarily in the most straightforward way, I go to great lengths to do
them the same way the hardware does it. Despite this, parts of the code are
exceedingly fast, other parts are rather slow. I think many purists will
eventually look at my code and say "this is going WAY too far just for the
sake of having the code execute the same way the real hardware does". I
realize that, but for me it's a labor of love and a way of learning the
machine completely.
The biggest thing that caused me a huge delay in this project was fully
gnu-izing it. I hadn't built anything complex using automake, autoconf,
libtool, texi, etc. That was a huge learning curve. I decided to implement
custom microcode (and HP microcode for that matter) as dynamic loadable code
via ltdl. Many would consider this overkill but it seemed a very logical way
to do it. That was another learning curve. As I'm sure many will attest,
learning autotools & friends from scratch can be a daunting process! Not to
mention the fact that every time I turn around, the autotools go through
dramatic changes. I follow the autotools mailing lists and they keep
changing fast the past year or two.
I tried a time or two to get additional developers to help, but no one
really stepped up to the plate so I just worked on it when I could. Ok, now
you have me interested in it again, maybe it's time to dust it off......
Jay West
PS - I don't recall talking about HPEMU much besides here, where did you
hear about it?