I thought I'd note that the divide problem couldn't have been patched with a micro code patch. It was because one of the ROM arrays used as part of the divide lookup was missing its data. It would have been much more than a simple patch to fix. It would have had to go back to a full subroutine patch. Today's processors are still memory bound for speed, even with local cache. It is mostly poor coding from the compilers for instruction cache issue but data is also a problem as larger memory addressing has made it so that cache misses are more common. Some of the instruction misses are helped by pipe depth but misses become more of an issue as one has a deeper pipe. Again, it is the current compilers that often make larger pipe depth impractical. It was this that made the need for speculative execution necessary. This was the cause of all security issues of late. In any case, it all comes back to memory latency. All the tricks to minimize its effect have caused other issues. It is still the biggest single issue blocking higher speed processors. The 5 GHz wall is also there but is being fudged around by minimizing the active circuits at any one time. It buys a little but don't expect to see 10 GHz processors any time soon on silicon. Dwight ________________________________ From: cctalk <cctalk-boun...@classiccmp.org> on behalf of Diane Bruce via cctalk <cctalk@classiccmp.org> Sent: Wednesday, January 2, 2019 12:09 PM To: Paul Koning; General Discussion: On-Topic and Off-Topic Posts Subject: Re: Microcode, which is a no-go for modern designs
On Wed, Jan 02, 2019 at 02:37:44PM -0500, Paul Koning via cctalk wrote: > > > > On Jan 2, 2019, at 2:31 PM, Chuck Guzis via cctalk <cctalk@classiccmp.org> > > wrote: > > > > On 1/2/19 10:44 AM, Guy Sotomayor Jr wrote: > > > >> Also, recall that there are different forms of micro-code: horizontal > >> and vertical. I think that IBM (in the S/360, S/370, S/390, z/Series) > >> uses the term micro-code for horizontal micro-code and millicode > >> for vertical microcode. > > > > On the CDC STAR-100, "microcode" as such was a relatively recent concept > > and the designers went overboard, mostly because of an ill-defined > > customer base (hence, BCD and other commerical-class instructions, like > > translate, edit and mark, etc.). The STAR is basically a RISC-type > > vector architecture with a pile of microcoded instructions bolted on. > > ... > > For a compiler writer, or even an assembly coder, this was more of a > > problem--which combination of instructions could be used to the greatest > > effect? And why do I have to have the hardware manual on my desk to > > look up instructions? > > That reminds me of the Motorola 68040. I used that at DEC in a high speed > switch (DECswitch 900 -- FDDI to 6 Ethernet ports). When studying the > instruction timings, I realized there is a "RISC subset" of the instructions > that run fast, a cycle or so per instruction. But the more complex > instructions are much slower. So the conclusion for a fastpath writer is to > use the RISC subset and pretend the fancy addressing mode instructions do not > exist. Which then reminds me further of the Coldfire processor which *did* remove the more complex instructions from the chip! > > paul > Diane -- - d...@freebsd.org d...@db.net http://artemis.db.net/~db
