The following message is a courtesy copy of an article that has been posted to bit.listserv.ibm-main,alt.folklore.computers as well.
[EMAIL PROTECTED] (Craddock, Chris) writes: > I never actually met a processor with the (mythical?) APL assist > feature. However, I did write mountains of APL throughout the 1980s. APL > was always thought of as a resource hog. IMHO it could be very efficient > or grotesque, depending on your data structures and algorithms. If you > wrote programs in the style of 3 GLs, it was typically a dog. re: http://www.garlic.com/~lynn/2007k.html#65 Non-Standard Mainframe Language? APL microcode assist was done for the 370/145 by the Palo Alto Science Center ... sort of as part of their doing APL\CMS. This was also made available on 370/148. As mentioned, the Cambridge Science Center had originally done the port of APL\360 to CMS for CMS\APL (i.e. back when it was Cambridge Monitor System for CP67; as part of the morph of CP67 to VM370 they "renamed" CMS the Conversational Monitor System). APL microcode assist gave APL\CMS applications on 370/145 about the same processor thruput as same APL\CMS application running on 370/168 (nearly ten times thruput increase). When the HONE datacenters were consolidated in silicon valley (actually across the back parking lot from the Palo Alto Science Center) ... they looked at whether they take any of their APL application intensive workload and move them off 168s to 145s. The problem was not only were their applications quite processor intensive (which 145 microcode assist would have given about equivalence) but also real storage and I/O intensive (which would have severely degraded if they had moved from 168 to 145/148). For nearly 15 yrs, i provided highly modified/customized versions of cp67 kernel and later vm370 kernels for HONE (and large number of other internal datacenters). I also periodically got involved in reviewing various APL applications from performance tuning standpoint ... aka majority of the applications that provided world-wide support for sales and marketing were implemented in APL running on CMS. Lots of past posts mentioning HONE and/or APL http://www.garlic.com/~lynn/subtopic.html#hone Eventually there was a APL language development group formed in STL which picked up APL\CMS responsibility as well as making it available on MVS ... renaming it VS\APL (and later APL2). Trivia ... in the early to mid 80s, the manager of the APL group in STL transferred to Palo Alto to head up a new group doing a port of BSD Unix to 370. I got to attend some of the design sessions and also help obtain a 370 C compiler for the effort. Before that specific implementation shipped, the group had their BSD porting efforts retargeted to the PC/RT ... eventually shipping "AOS" (the C compiler vendor being used had to retarget the backend from 370 to ROMP). misc. past posts mentioning 801/ROMP as well as risc, Iliad, RIOS, rs/6000, power/pc, etc http://www.garlic.com/~lynn/subtopic.html#801 The APL microcode assist was not made available on other processors. The 145/148 microcode engine was a vertical microcode engine and executing approx. 10 microcode instructions per every 370 instruction (some of the modern i86-based 370 simulators have similar ratio characteristics). The 370/165 had a horizontal microcode engine ... and achieved an avg. of 2.1 machine cycles per 370 instruction ... which was improved to 1.6 machine cycles per 370 instruction (and hit nearly 1:1 with 3033). Since 370 instructions were executing very close to hardware speed on the high-end processors ... there was frequently very little performance benefit of doing a 1-for-1 translation of 370 instruction into native hardware. The exception was virtual machine microcode assists on the high-end processors ... however these weren't the 1:1 translation of 370 instructions to native instructions. In the virtual machine assists, the instruction emulation for privilege instruction was modified to directly perform the privilege operation while in problem state (but according to "virtual machine" execution rules ... sort of a "3rd" machine state). This avoided the interrupt into the kernel, having to save registers and other state change overhead ... redecode the operation in software and perform the necessary operation, and then switch back to virtual machine problem state execution. In addition to stuff like APL microcode assist done for 145/148 ... there was the VM kernel assist "ECPS" done for both 138 & 148. This took about 6k bytes of vm370 370 kernel code and moved it into native microcode of the machines (again getting about 10:1 thruput improvement). some old posts about how we went about selecting what parts of the kernel code were moved into microcode (some of the initial work involved help from some of the same people involved in doing the 145 APL microcode assist) http://www.garlic.com/~lynn/94.html#21 370 ECPS VM microcode assist http://www.garlic.com/~lynn/94.html#27 370 ECPS VM microcode assist http://www.garlic.com/~lynn/94.html#28 370 ECPS VM microcode assist and lots of past posts discussing all sort of vertical and horizontal native machine microcode http://www.garlic.com/~lynn/subtopic.html#mcode ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
