16 Sep
2020
16 Sep
'20
6:41 p.m.
Warner asks:
"Why was microcode support required to make APL work? What did it enable
that couldn't be done in other ways?" [On an HP 3000 Series III, for
example]
Back in the mid-1970s, on the HP 3000 Series III, the team implementing
APL\3000 apparently decided they would need to implement some form of
virtual memory (beyond the multiple 64KB spaces the HP 3000 Classic
architecture provided). They chose to add 11 new instructions:
LDV, STV, MWFV, MWTV, MBFV, MBTV, LDVB, STVB, MVW,
and EGOTO (unnamed by HP), LDWX (unnamed by HP)
The first 9 are "virtual memory" related instructions. The last two are
not.
These instructions were added shortly after the original Series III
instruction set had previously been expanded by the addition of the new
extended COBOL instructions. (So, the Series III had two sets of firmware
expansions.)
Subsequent HP 3000 models had the COBOL instructions from day 1.
I presume that the APL instructions weren't ready when the Series 30/33
design was locked down. I *think* they might have been available later as
an add-on.
I know that a few years later, the instructions were ported to the Series
40/44 microcode by Leon Leong, but they were never released for it
(APL\3000 was in limbo, about to be cancelled at the time.)
But, to answer your question, yes...there are other ways.
Gavin Scott managed to patch the unimplemented instruction handler in MPE
V/R (the release the SIMH HP3000 simulator is running), and got APL\3000
running. In the meantime, I'm slowing trying to add the instructions to
the SIMH code. The nice thing about Gavin's approach is that if I get an
instruction implemented, his code *for that instruction* simply never gets
called ... so we can coexist peacefully. In theory, implementing the APL
instructions in SIMH will lead to better performance (because calling one
won't cause a missing instruction interrupt, followed by hundreds or
thousands of simulated HP 3000 instructions to emulate the instruction).
I believe Gavin is preparing a talk about APL\3000 for an APL Users Group.
Another alternative would have been for the APL\3000 people to implement
references to their virtual memory via "cover functions". However, I
suspect that the grasp of SPL programming, the lack of "macros" with
parameters in SPL, and concerns about the performance penalty of a
procedure call per memory access all would have conspired to argue against
this approach.
(Having been reading thousands of lines of SPL written in the 1970s, I
conclude that perhaps a handful of people at HP understood how to write
readable, maintainable SPL code ... and that's probably the same percentage
as SPL programmers outside HP :)
Stan