[email protected] (Timothy Sipples1) writes: > Keep in mind that for 1975 this was absolutely amazing technology, but > amazing technology required some expense. Being early is pricey. If the > 5100 debuted in, say, 1977 or 1978, it would have still been well timed but > could have dramatically reduced the chip and board count. I also think the > small built-in monitor could have been sacrified (at least as an option) in > favor of a display port of some kind -- ideally RF for TV hookup. And IBM > might have gone with a diskette drive for storage -- the 5100 was too early > for the 5.25 inch drive, which debuted in 1976. Finally, if IBM had > provided a little more guidance on the 370 subset instruction set they > implemented, software developers could have taken over from there. > > So I think the 5100 could have been a nice 5110 by tweaking the recipe a > bit. But history didn't happen that way.
re: http://www.garlic.com/~lynn/2012l.html#72 zEC12, and previous generations, "why?" type question - GPU computing http://www.garlic.com/~lynn/2012l.html#74 zEC12, and previous generations, "why?" type question - GPU computing http://www.garlic.com/~lynn/2012l.html#77 zEC12, and previous generations, "why?" type question - GPU put all logic in microcode http://en.wikipedia.org/wiki/IBM_PALM_processor 5100 had enuf 360 microcode emulation to run apl/360 http://en.wikipedia.org/wiki/IBM_5100 from above: The 5100 was based on IBM's innovative concept that, using an emulator written in microcode, a small and relatively cheap computer could run programs already written for much larger, and much more expensive, existing computers, without the time and expense of writing and debugging new programs. Two such programs were included: a slightly modified version of APL.SV, IBM's APL interpreter for its System/370 mainframes, and the BASIC interpreter used on IBM's System/3 minicomputer. Consequently, the 5100's microcode was written to emulate most of the functionality of both a System/370 and a System/3. IBM later used the same approach for its 1983 introduction of the XT/370 model of the IBM PC, which was a standard IBM PC XT with the addition of a System/370 emulator card. ... snip ... part of the issue was apl code was fairly dense ... and apl\360 workspaces were typically 16kbytes (some systems offerred 32kbytes). cambridge science center had taken apl\360 ... stripped out all the multitasking and swapping stuff and got it to run under cms workspace as large as virtual memory ... for cp67 cms\apl. some amount of work had to be done on how apl\360 storage since it tended to use all available workspace ... which resulted in page thrashing in virtual memory environment. there was also an cms\apl API to access system services (including file i/o). The combination of large workspace and file i/o allowed doing a lot of real-world applications (that couldn't be done with apl\360). The business planners in Armonk loaded the holiest of holy data (detailed customer profiles) on the cambridge system for business modeling in cms\apl. This also created something of security issue since cambridge also allowed non-employee access from various institutions in the cambridge area (students, staff, faculty). palo alto science center then did the enhancements to make vm370 apl\cms ... they also did the 370/145 apl microcode assist and the 5100. the person that did 370/145 apl microcode assist was also instrumental in many of the fortan hx performance enhancmenets. -- virtualization experience starting Jan1968, online at home since Mar1970 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
