Re: Slushware
W dniu 2014-12-28 o 14:55, Phil Smith pisze: Alan Altmark wrote: Microcode is burned into the CPUs, being the on-chip logic that actually runs the native instruction set. Alan, by that definition, none of us have ever applied a microcode patch. Yet I remember distinctly doing so (box after box of 1.44MB floppies!). So either IBM has changed the meaning of the term, which doesn't quite make sense, or I was hallucinating. Plus I'm not sure what the distinction would be between microcode and the actual raw chip instruction set in this case?! IMHO it is just multiple meanings of microcode. Alan's definitions comes form detailed view (narrowed to CPU), but there is also general view, which (implicitly) defines microcode as any firmware code in the hardware or any code under OS. Using general view a microcode is HMC code, including it's operating system (yes, OS/2 was a microcode in terms and conditions and patching process!), it can be OSA card firmware (with Linux as a part of it!), it can be firmware of tape drive (i.e. including Sinix operating system for 3490E-Fxx). This is functional approach - Linux on OSA is a microcode for me as OSA user. -- Radoslaw Skorupka Lodz, Poland -- Tre tej wiadomoci moe zawiera informacje prawnie chronione Banku przeznaczone wycznie do uytku subowego adresata. Odbiorc moe by jedynie jej adresat z wyczeniem dostpu osób trzecich. Jeeli nie jeste adresatem niniejszej wiadomoci lub pracownikiem upowanionym do jej przekazania adresatowi, informujemy, e jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne dziaanie o podobnym charakterze jest prawnie zabronione i moe by karalne. Jeeli otrzymae t wiadomo omykowo, prosimy niezwocznie zawiadomi nadawc wysyajc odpowied oraz trwale usun t wiadomo wczajc w to wszelkie jej kopie wydrukowane lub zapisane na dysku. This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorized to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. mBank S.A. z siedzib w Warszawie, ul. Senatorska 18, 00-950 Warszawa, www.mBank.pl, e-mail: kont...@mbank.pl Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, nr rejestru przedsibiorców KRS 025237, NIP: 526-021-50-88. Wedug stanu na dzie 01.01.2014 r. kapita zakadowy mBanku S.A. (w caoci wpacony) wynosi 168.696.052 zote. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Slushware
In 7536935054212770.wa.alanaltmarkus.ibm@listserv.ua.edu, on 12/29/2014 at 12:09 AM, Alan Altmark alan_altm...@us.ibm.com said: When we first started using the word microcode I believe it was correct. Then we split the microcode into a burned-in part and a loadable part, so the word came to mean reloadable microcode. Feh. It was no longer really microcode, but there wasn't a term for what it was. So we introduced the term millicode. As the CPU architecture got more and more complex and functionally rich, microcode was left to flounder with no clear meaning. That's not what you folks wrote when you introduced the term; technical articles described a hierarchy of microcode, millicode and z, with the millicode using an extended subset of the z instruction set and the microcode using an undocumented architecture, presumably VLIW (horizontal). -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Slushware
Thanks, Alan-as with so many such things, the real answer is thus It depends! (where have I heard THAT before?). And it's a multivariable dependency: when, where, why, how... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Slushware
In 6469079386912310.wa.alanaltmarkus.ibm@listserv.ua.edu, on 12/29/2014 at 10:44 AM, Alan Altmark alan_altm...@us.ibm.com said: Yes, lots of articles, and at the end of the day, you still have no idea how the machine you have is implemented. Well, we used to, back when customers could order CE manuals that gave the details. These days, you get broad brush overviews that tell you that, e.g., the millicode is an extended subset of z but not what instructions were removed or what was added. As you noted, the allocation among the levels and even the number of levels changes from generation to generation. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Slushware
Am 29.12.2014 um 17:44 schrieb Alan Altmark: But my experience within IBM is that that we love talking about technology. In fact, we sometime love it a bit too much, particularly when it's new and it hasn't completed its evolutionary journey. That's true. I'm in the software business, and for me such software is best that makes absolutely no assumptions about the underlying hardware and runs on all platforms. This is not always possible, of course, but I normally don't need to know which aspect of the architecture is implemented at which layer of the machine (although I find such discussions interesting, too). Kind regards Bernd -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Slushware
On Mon, 29 Dec 2014 10:44:20 -0600, Alan Altmark wrote: Don't get me wrong. A machine that was designed to let you change the underlying hardware design without altering the programming architecture of the machine was very smart. And way cool. And a major move forward in the industry. There's a reason the architecture has survived for 50 years with those old 24-bit applications still running just fine thank-you-very-much. Alternatives are: o HLL with architecture-specific compiler variants. This provides me portability over (at least) z, Intel, and Sparc. IBM might see this as a negative business value. o Emulators. Mac OS has survived three radically different hardware platforms (M68K, PPC, I86) and two OS platforms with emulation bridges at each transition. Very effective. When I (belatedly) upgrade I'll need to recompile my PPC programs. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Slushware
I suspect returning to that level of frankness would get you into machine instruction timings - and all that goes with it. :-) Cheers, Martin Martin Packer, zChampion, Principal Systems Investigator, Worldwide Banking Center of Excellence, IBM +44-7802-245-584 email: martin_pac...@uk.ibm.com Twitter / Facebook IDs: MartinPacker Blog: https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker From: Shmuel Metz (Seymour J.) shmuel+ibm-m...@patriot.net To: IBM-MAIN@LISTSERV.UA.EDU Date: 29/12/2014 17:03 Subject:Re: Slushware Sent by:IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU In 6469079386912310.wa.alanaltmarkus.ibm@listserv.ua.edu, on 12/29/2014 at 10:44 AM, Alan Altmark alan_altm...@us.ibm.com said: Yes, lots of articles, and at the end of the day, you still have no idea how the machine you have is implemented. Well, we used to, back when customers could order CE manuals that gave the details. These days, you get broad brush overviews that tell you that, e.g., the millicode is an extended subset of z but not what instructions were removed or what was added. As you noted, the allocation among the levels and even the number of levels changes from generation to generation. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Slushware
In ofc877ce3b.427af753-on80257dbd.0062c865-80257dbd.0062e...@uk.ibm.com, on 12/29/2014 at 06:00 PM, Martin Packer martin_pac...@uk.ibm.com said: I suspect returning to that level of frankness would get you into machine instruction timings - and all that goes with it. :-) Those were already unwieldy the last time that IBM published them, and they would be much more complicated today. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Slushware
alan_altm...@us.ibm.com (Alan Altmark) writes: Yet you never hear millicode being applied to storage controllers or other parts outside of the processor. And you know as well as I do that they aren't replacing microcode on the processor chips. They're replacing the OS and the applications that use them. But we continue to call it microcode. The joke's on us re: http://www.garlic.com/~lynn/2014m.html#161 Slushware http://www.garlic.com/~lynn/2014m.html#163 Slushware http://www.garlic.com/~lynn/2014m.html#164 Slushware http://www.garlic.com/~lynn/2014m.html#166 Slushware 79/80 there was effort to replace the myriad of internal microprocessors with 801/risc ... 801 Iliad chips for the low mid-range 370s, 801 ROMP chip for the follow-on to the displaywriter, new 801 chip for the AS/400 (follow-on to s/36 s/38), 801 chips for wide variety of (disk, tape, communication, etc) controlers, etc. For various reasons all of these failed and things returned to business as usual with various CISC chips ... and started to see 801 chip engineers leaving to other vendors to work on risc programs there. the followon to 4331/4341, 43614381 were originally to be 801 microprocessors with 370 simulation done in 801 software ... rather than whatever preceeding CISC processors were used (vertical microcode that avg. ten native instructions per 370 instruction). There was even work on JIT (just in time dynamic compiling of 370 into native 801/risc) ... somewhat analogous to what is seen with some modern day JAVA. I helped with white paper that shot down the use of 801/Iliad for 4381 ... the story was that CISC chips were getting sophisticated enough that much of 370 instructions could be directly implemented in silicon ... rather than having to be all simulation in microcode (software) ... resulting in significant better price/performance. as/400 eventually abandoned 801/risc implementation, changing to traditional CISC microprocessor. However, a decade later AS/400 did move over to 801/risc with power/pc. past 801/risc, iliad, romp, rios, power, etc posts http://www.garlic.com/~lynn/subtopic.html#801 A little later, IBM Germany did the (native) 370 ROMAN chipset. Somehow somebody in Nixdorf (did 370 clones) came into possession of detailed specs. for ROMAN. He sent it to somebody at Amdahl that he had been working with ... who presented it to me to return to the rightful owners (trying to avoid any litigation that might come from having come into the possession of the document). Turns out that I was trying to get a project going to package a few dozen ROMAN chipsets in a rack. It was sort of followon to something I had gotten dragged into a few years earlier. I had access to engineering 4341 (before first customer ship) and got asked to do some benchmarking for LLNL that was looking at getting 70 4341s for compute farm (sort of precursor to modern grid supercomputing). A cluster of 4341s had more computer power than high-end mainframes, were much cheaper, and required much less floor space and environmentals. old 4341 email http://www.garlic.com/~lynn/lhwemail.html#4341 later I got involved in doing something similar ... but packing as many 801/RIOS chips in a rack as possible (instead of 370/ROMAN). some old email http://www.garlic.com/~lynn/lhwemail.html#medusa -- virtualization experience starting Jan1968, online at home since Mar1970 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Slushware
Alan Altmark wrote: Microcode is burned into the CPUs, being the on-chip logic that actually runs the native instruction set. Alan, by that definition, none of us have ever applied a microcode patch. Yet I remember distinctly doing so (box after box of 1.44MB floppies!). So either IBM has changed the meaning of the term, which doesn't quite make sense, or I was hallucinating. Plus I'm not sure what the distinction would be between microcode and the actual raw chip instruction set in this case?! ...phsiii -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Slushware
In 84bccd71182f0046bcd2fb054fe5237917b2ee2...@hqmailsvr02.voltage.com, on 12/27/2014 at 09:17 AM, Phil Smith p...@voltage.com said: This is fun. I'm not sure modern machines are both microcoded AND millicoded-I thought millicode was just another form of microcode. Am I wrong? Yes; millicode is the same as what Amdahl called macrocode, and is one level up from microcode, using (mostly) normal S/3x0 instructions. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Slushware
The shop I worked at in the late 70s had an Amdahl box. Don't remember the model; it was red, if that helps. The newest version of MVS came with a test early in NIP to check for supported hardware. It executed an instruction that our Amdahl box did not have in its arsenal. On our machine, this would cause a S0C1. There were other 'new' instructions in the OS as well, rendering the box pretty much useless. Amdahl to the rescue. They gave us a software usermod that would get control for any program interrupt. If it was a S0C1, the code would check for one of the new instructions. If not one of those, the error would percolate. If it was an unsupported instruction, the Amdahl code would simulate the function provided by the missing instruction, which in some cases meant doing nothing at all. Before returning control to the mainline, the usermod would replace the original instruction in memory with either a direct branch to the simulation routine or else a NOP if there was nothing to do. Early in the IPL life, there would be lots of S0C1 interrupts, but as time went on there would be fewer and fewer as the offending instructions were replaced. It worked amazingly well. . . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile jo.skip.robin...@sce.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Shmuel Metz (Seymour J.) Sent: Sunday, December 28, 2014 10:27 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Slushware In 84bccd71182f0046bcd2fb054fe5237917b2ee2...@hqmailsvr02.voltage.com, on 12/27/2014 at 09:17 AM, Phil Smith p...@voltage.com said: This is fun. I'm not sure modern machines are both microcoded AND millicoded-I thought millicode was just another form of microcode. Am I wrong? Yes; millicode is the same as what Amdahl called macrocode, and is one level up from microcode, using (mostly) normal S/3x0 instructions. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Slushware
re: http://www.garlic.com/~lynn/2014m.html#161 Slushware http://www.garlic.com/~lynn/2014m.html#163 Slushware http://www.garlic.com/~lynn/2014m.html#164 Slushware as an aside ... the hardware layer from i86 instructions to risc micro-ops for execution ... isn't serialized ... it is pipelined operation ... simple version starts with overlapping instruction fetch decode with instruction execution http://en.wikipedia.org/wiki/Instruction_pipeline the above mentions that pentium4/pentuimD had 31-stage pipeline ... longest in mainstream consumer computing longer pipeline affects the latency for any specific instruction getting executed ... but isn't (necessarily) limiting in the aggregate instruction execution rate (since the operations are overlapped in parallel). there was recent claim (in ibm linkedin discussion) that there is approx. mainframe aggregate 18-20 milllion MIPS in the world today ... or the equivalent of around 270 max. configured EC12s (@75BIPS) ... or about 15 e5-2699v3 blades (@1.3TIPS). A typically cloud megadatacenter can have several hundred thousand blades ... and a standardized virtualization/container facility goes a long way to simplifying the operation. http://www.networkcomputing.com/cloud-infrastructure/virtual-machines-vs-containers-a-matter-of-scope/a/d-id/1269190 -- virtualization experience starting Jan1968, online at home since Mar1970 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Slushware
On Sun, 28 Dec 2014 05:55:09 -0800, Phil Smith p...@voltage.com wrote: Alan, by that definition, none of us have ever applied a microcode patch. Yet I remember distinctly doing so (box after box of 1.44MB floppies!). So either IBM has changed the meaning of the term, which doesn't quite make sense, or I was hallucinating. Plus I'm not sure what the distinction would be between microcode and the actual raw chip instruction set in this case?! Technically, microcode is what decodes instructions, puts data on the buses, moves data into and out of registers, and turns the logic gates on and off. It need have no similarity to what you read in a programming reference. When we first started using the word microcode I believe it was correct. Then we split the microcode into a burned-in part and a loadable part, so the word came to mean reloadable microcode. Feh. It was no longer really microcode, but there wasn't a term for what it was. So we introduced the term millicode. As the CPU architecture got more and more complex and functionally rich, microcode was left to flounder with no clear meaning. So today we have firmware that is an accretion of all of the things that can be changed without replacing parts, millicode to identify the firmware that implements the architecture, and microcode to mean everything that isn't millicode. Yet you never hear millicode being applied to storage controllers or other parts outside of the processor. And you know as well as I do that they aren't replacing microcode on the processor chips. They're replacing the OS and the applications that use them. But we continue to call it microcode. The joke's on us If you try to create clear-cut definitions of the terms, you will be frustrated. It's best to go read what Humpty Dumpty has to say to Alice about the meaning of words. When I hear them, I wait for context to surface and then just say to myself, Oh. THAT part of The System. :-) Alan Altmark IBM -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Slushware
On Fri, 26 Dec 2014 05:55:57 -0600, Shane Ginnane wrote:
I sometimes wonder when was the last time anyone installed to a real piece
of hardware - no {pico,micro,macro)-code.
Slushware is ubiquitous.
The corollary of course is how do vendors like vmware and IBM convince
customers for continue to pay for hipervisors ?.
z/OS is not the only golden goose apparently.
It began nearly a half century ago with microcode implementation of S360
models, and only slightly later, W. M. Waite's Mobile Programming System.
Nowadays:
microcode-millicode-PR/SM-VM-JVM-byte code
How many layers have I neglected? Hercules is a confluent branch.
-- gil
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Slushware
Paul Gilmartin wrote: It began nearly a half century ago with microcode implementation of S360 models, and only slightly later, W. M. Waite's Mobile Programming System. Nowadays: microcode-millicode-PR/SM-VM-JVM-byte code How many layers have I neglected? Hercules is a confluent branch This is fun. I'm not sure modern machines are both microcoded AND millicoded-I thought millicode was just another form of microcode. Am I wrong? To make it more exciting, how about this perversion (I'm removing microcode just in case): millicode==PR/SM==z/VM==Linux==Bochs==Windows That's one more than your layering (whether microcode still exists or not)! Now, will it be speedy? I think not... ...phsiii -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Slushware
000433f07816-dmarc-requ...@listserv.ua.edu (Paul Gilmartin) writes: It began nearly a half century ago with microcode implementation of S360 models, and only slightly later, W. M. Waite's Mobile Programming System. Nowadays: microcode-millicode-PR/SM-VM-JVM-byte code How many layers have I neglected? Hercules is a confluent branch. note that the original hypervisor was done by Amdahl in something called macrocode ... which was a layer above microcode and very close to standard 370. In the mid-70s, I had been sucked in by Endicott to help with microcode assists for 138/148 ... vertical microcode machine that avg. 10 microcode instructions per 370 instruction (not that different from the various intel based simulators). Was told that there were 6kbytes available for microcode and kernel instruction sequences dropped into microcode on nearly byte for byte ... so was to identify the top 6kbytes worth of kernel instruction sequences ... that would be moved to microcode for a 10:1 performance improvement. Old post with results of analysis ... turns out top 6kbytes of instruction sequences accounted for 79.55percent of kernel time. http://www.garlic.com/~lynn/94.html#21 In any case, I was giving presentations on the effort at the monthly bay area user group meetings (BAYBUNCH) held at SLAC ... and the Amdahl people were pumping me for additional details at the get togethers held at local watering holes after the meetings (this was before hypervisor was announced). After hypervisor was announced ... the 3090 was eventually forced to respond with PR/SM. Part of the issue was that 3090 was horizontal microcode machine ... which was enormously more difficult to program for than 370 instructions ... and was much more difficult. I had been told that Amdahl had original evolved macrocode to respond to the enormous number of architecture tweaks that IBM had been doing on their high-end (vertical microcode machines) starting with the 3033 and continued through 3081 (macrocode used to drastically reduce the effort needed to respond). I've mentioned before ... during FS period ... internal politics were killing off 370 efforts (the lack of 370 products during this period is credited with giving clone processor makers a market foothold) ... then when FS imploded there was mad rush to get 370 products back into pipeline. POK kicked off 3033 (initially 168 logic remapped to 20% faster chips) and 3081 in parallel ... more detailed account here: http://www.jfsowa.com/computer/memo125.htm since that neither 3033 or 3081 were really that competitive, the architecture tweaks would supposedly give the machines competitive advantage ... many were claimed to be performance improvements ... but folklore is that many actually ran slower (than native 370). Part of the issue is the high-end, horizontal microcode machines were profiled in terms of avg. machine cycles per 370 instruction ... by 3033, this was done to cloe to one machine cycle per 370 instruction (370 instruction move to microcode couldn't see the 10:1 improvement seen on the vertical microcode machines). In anycase, it sort of drove Amdahl into creating macrocode as a way of drastically simplifying being able to respond to the increased architecture tweaking. The other factor was that part of the mad rush after FS failure, the head of POK managed to convince corporate to kill off vm370, shutdown the development group and move all the people to POK ... or otherwise POK would be able to make mvs/xa ship schedule several years (Endicott managed to save the vm370 product mission, but had to reconstitute a development group from scratch). Part of the POK activity was creating a XA vritual machine VMTOOL (to support MVS/XA development) that was never intended to be made available to customers. After initial introduction of 370/xa and MVS/XA ... there was very slow uptake ... customers continued to run 3081s in 370 mode with MVS (or vm370). The decision then was to release the VMTOOL as the migration aid ... allowing customers to run both MVS and MVS/XA concurrently on the same machine as aid to migration. Amdahl solution was the hypervisor which provided the same capability ... but much more efficiently. IBM eventually responded with PR/SM on the 3090 ... but it was much greater effort because it required being all done in native horizontal microcode. The POK(/Kingston) group then pushed very hard to have migration aid morph into standard VM/XA product. The problem was that VMTOOL had only been developed for MVS/XA development and lacked lots of function and performance features (especially compared to vm370 of the period) and was going to require lots of resources, effort and time to bring up to compareable level of vm370. Somebody at an internal datacenter had made the changes to vm370 to provide full function 370/XA support ... which would have been trivial to release. In the internal politics between POK and Endicott, POK managed to prevail and
Re: Slushware
000433f07816-dmarc-requ...@listserv.ua.edu (Paul Gilmartin) writes: How many layers have I neglected? Hercules is a confluent branch. re: http://www.garlic.com/~lynn/2014m.html#161 Slushware http://www.garlic.com/~lynn/2014m.html#163 Slushware for other hercules drift ... risc processors had performance advantage over intel ... risc having made extensive use of technolology to compensate for the increasing mismatch between memory latency and processor speed ... out-of-order execution, speculative execution, branch-prediction, etc ... sort of the hardware equivalent of '60s multiprogramming to keep processor busy while waiting for disk access (current memory latency, measured in count of cpu cycles is compareable to 60s disk latency when measured in number of 60s cpu cycles). however, for nearly 20yrs, intel has gone to hardware layer that translates intel instructions into risc micro-ops for execution ... largely negating any risc performance advantage. note that somewhat similar (out-of-order, etc) technology started to be introduced for z196 ... claiming it provided over half the performance improvement from z10 to z196 ... and further additions responsible for some of the z196 to ec12 performance improvement. another technology (compensating for stalled instructions) is hyperthreading. I first ran into it when I was asked to help 370/195 for a hyperthreading implementation they wanted to do. 370/195 had pipeline supporting out-of-order execution that could run at 10mips ... but didn't have branch prediction ... so conditional branches would stall the pipeline ... many codes only ran at 5mips. The idea was to simulate multiprocessor operation with two instruction streams, registers ... but still the same pipeline and execution units (two 5mip instruction steams keeping the 10mip execution units busy). note that it dates back to acs/360 in the late 60s ... see multithreading reference near the end of this article http://people.cs.clemson.edu/~mark/acs_end.html also referenced here http://en.wikipedia.org/wiki/Simultaneous_multithreading SPARC T5 can have 8chips/system, 16cores/chip and 128threads/chip (aka 8threads/core) http://en.wikipedia.org/wiki/SPARC_T5 by comparison, about same time as ec12, e5-2600v1 had two 8core chips for 16cores total and 400-600+ BIPS rating (depending on model) ... compared to max configured (101 processors) EC12 @75BIPS. both e5-2600v1 and ec12 processor chips are done in 32nm technology. intel has a tick-tock chip generation http://en.wikipedia.org/wiki/Intel_Tick-Tock alternates shrinking previous chip design with new technology (tick, e5-2600v2 22nm tech) and then designing new chip for the new technology (tock, e5-2600v3 redesign 22nm). some e5-2600v3 ( v4) discussion http://techgadgetnews.com/2014/09/21/intel-xeon-e5-2600-v3-haswell-ep-workstation-and-server-processors-unleashed-for-high-performance-computing/ E5-2690v1 at 632BIPS, E5-2690v2 at 790BIPS, E5-2690v3 at 996BIPS, E5-2699v3 at 1.321TIPS. http://www.tomshardware.com/reviews/intel-xeon-e5-2600-v3-haswell-ep,3932-7.html note MIPS/BIPS/TIPS are benchmark iterations compared to 370/158 assumed to be 1MIP processor. -- virtualization experience starting Jan1968, online at home since Mar1970 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Slushware
On Sat, 27 Dec 2014 09:17:20 -0800, Phil Smith p...@voltage.com wrote: This is fun. I'm not sure modern machines are both microcoded AND millicoded-I thought millicode was just another form of microcode. Am I wrong? Sure. Millicode sits between your program and the machine's native instruction set. It is part of the firmware, meaning it can be changed. It primarily intercepts any non-native instruction and breaks it down into a sequence of native instructions or redirects that data to another processor. Microcode is burned into the CPUs, being the on-chip logic that actually runs the native instruction set. In rare cases millicode may intercept a native instruction and re-implement it, such as might be done if an error is found in microcode or chip design too late or too expensive to fix. A z/Architecture instruction may shift from millicode to native and back several times over its life as the underlying chip design changes. Alan Altmark IBM -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Slushware
On Fri, 26 Dec 2014 05:25:41 -0500, John Gilmore wrote:
If one finds it amusing to do so, the reductionist game of describing
underlying reality can be played over and over again
I sometimes wonder when was the last time anyone installed to a real piece of
hardware - no {pico,micro,macro)-code.
Slushware is ubiquitous.
The corollary of course is how do vendors like vmware and IBM convince
customers for continue to pay for hipervisors ?.
z/OS is not the only golden goose apparently.
Shane ...
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
