I'm actually working on the Alpha implementation right now, during my not-as-free-as-I-would-like time.
Why is it taking so long? ------------------------------- The Alpha is amazingly complex, as you have to simulate the entire set of PC devices (JDEC memory, RT Clock, APICs, Serial Ports, etc.) and buses (PCI, ISA, EISA, SCSI, USB, etc.) that have not been developed for SIMH yet. I have recently found almost all of the needed PC device simulation logic in the QEMU code base, and might be able to port that logic into the SIMH simulator to speed up the development process. Driving the SCSI bus state transitions will be particularly time consuming without the real dedicated SCSI processors which were on every SCSI device and host card. I have the Alpha simulator booting and running some 68 million instructions before it gives up due to a "fatal hardware error", but it hasn't gotten up to the firmware chevrons (>>>) yet, as I haven't simulated most of the required hardware devices yet. The Alpha Firmware itself is a very complex OS, initializing and testing the hardware, and setting up all of the in-memory data structure required by the Alpha Architecture manual, before running the interactive console chevron dialog. What about JIT? -------------------- The emulator is also amazingly slow compared to real hardware due to the sheer number of emulated instructions executed and the emulation overhead. JIT would be a wonderful thing, but it's more important to get the emulation right than to make it work faster, as (theoretically) newer host hardware will eventually "catch up" to the emulation overhead. That said, the TCG (Tiny Code Generator) component of QEMU has made me think that we could "do some JIT" in SIMH, either at the single instruction level or at the block level. The primary impact of adding JIT to the emulator is that it throws the emulated clock off - SIMH time, IO, and polling works by counting emulated instructions, and if the emulation instruction count "jumps" because you executed a large block of JIT code, it could significantly delay or miss the response required for SIMH polling and simulated clock interrupts. It is unlikely that a SIMH Alpha emulation will ever hit the speeds of the commercial emulators, since SIMH is designed be portable, and the commercial emulators are tweaked for specific host platforms. Note that SIMH VAX has never hit the speeds posted by commercial VAX emulators, but runs on almost anything. It is probable that JIT would only be possible on specific host processors or host OS's, requiring that the emulator be capable of both JIT and non-JIT operation. If anyone would care to help in the Alpha development process, I can start checking my code in to allow other developers to assist. If you are interested in helping, send me an email. In the meantime, if you just want to run a free Alpha emulator, the FreeAXP emulator from MSI is and will continue to be available. David Hittner -----Original Message----- From: Simh [mailto:simh-boun...@trailing-edge.com] On Behalf Of Paul Koning Sent: Monday, November 20, 2017 8:58 AM To: Gordon Miller <gordonamille...@gmail.com> Cc: simh@trailing-edge.com Subject: EXT :Re: [Simh] Any chance of AXP for SIMH ? > On Nov 20, 2017, at 12:07 AM, Gordon Miller <gordonamille...@gmail.com> wrote: > > Hi guys > > I'm the new kid here, despite my grey hair. > > Anyway, what I'm quite interested in, is any kind of Alpha AXP support for > SIMH. Take a look at the current code, there is an "alpha" subdirectory. I don't remember the status of that, probably quite preliminary but there are at least some pieces in place. paul _______________________________________________ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh _______________________________________________ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
