2 Jan
2019
2 Jan
'19
12:31 a.m.
-----Original Message-----
From: cctalk [mailto:cctalk-bounces at classiccmp.org] On Behalf Of Carlo Pisani via
cctalk
Sent: Tuesday, January 01, 2019 5:35 PM
To: ben; General Discussion: On-Topic and Off-Topic Posts
Subject: Re: Motorola M88K books & user manuals (looking for)
I'm curious as to why you make this claim that microcode is no-go in
"modern" designs. Could you please elaborate on this point? I don't see
why the alternative random control logic would be a better proposition.
Thanks,
paul
I was never a fan of RISC architecture as does
not fit the standard high
level language model. Everybody wants a 1 pass compiler, thus the RISC
model. If you are doing your own RISC model, you might consider a model
that supports Effective addressing better since we have got the point
where fetching the data is taking longer than processing it.
yup. I am a 68k programmer so I know what you mean.
the 68k is more comfortable to be programmed in assembly, and even the
EA modes (especially in the 68020 and CPU32) help a lot.
unfortunately, the 68K is very complex to be designed, and the first
68020 used microcode, which is a no-go for modern designs.
... 
2 Jan
2 Jan
8:02 a.m.
On 01/02/2019 02:31 AM, Paul Birkel via cctalk wrote:
I'm
curious as to why you make this claim that microcode is no-go in "modern"
designs. Could you please elaborate on this point? I don't see why the alternative
random control logic would be a better proposition.
Random logic instruction decode was a REAL issue in about
1960 - 1965, when computers were built with discrete
transistors. The IBM 7092, for instance, had 55,000
transistors on 11,000 circuit boards. I don't know how much
of that was instruction decode, but I'll guess that a fair
bit was. The IBM 360's benefited from microcode, allowing
them to have a much more complex and orthogonal instruction
set with less logic.
But, once ICs were available, the control logic was less of
a problem. But, microcode still made sense, as memory was
so slow that performance was dictated by memory cycle time,
and the microced did not slow the system down. Once fast
cache became standard, then eliminating performance
bottlenecks became important. And, once we went from lots
of SSI chips to implement a CPU to one big chip, then it was
possible to implement the control logic within the CPU chip
efficiently.
Jon
10:22 a.m.
On 1/2/19 8:02 AM, Jon Elson via cctalk wrote:
Random logic instruction decode was a REAL issue in
about 1960 - 1965,
when computers were built with discrete transistors.? The IBM 7092, for
instance, had 55,000 transistors on 11,000 circuit boards.? I don't know
how much of that was instruction decode, but I'll guess that a fair bit
was.? The IBM 360's benefited from microcode, allowing them to have a
much more complex and orthogonal instruction set with less logic.
But, once ICs were available, the control logic was less of a problem.?
But, microcode still made sense, as memory was so slow that performance
was dictated by memory cycle time, and the microced did not slow the
system down.? Once fast cache became standard, then eliminating
performance bottlenecks became important.? And, once we went from lots
of SSI chips to implement a CPU to one big chip, then it was possible to
implement the control logic within the CPU chip efficiently.
I don't know--"microcode" in today's world is a very slippery term.
If
you're talking about vertical microcode, then I'm inclined to agree with
you. But even ARM, which is held up as the golden example of
microcode-less CPU design, is programmed via HDL, which is then compiled
into a hardware design, at least in instruction decoding. So ARM is a
programmed implementation. I suspect that if x86 microcode were to be
written out in HDL and compiled, Intel could make the same claim.
I think of it as being akin to "interpreted" vs. "compiled"
languages--the boundary can be rather fuzzy (e.g. "tokenizing",
"p-code", "incremental compilation"... etc.)
--Chuck
10:44 a.m.
On Jan 2, 2019, at 10:22 AM, Chuck Guzis via cctalk
<cctalk at classiccmp.org> wrote:
On 1/2/19 8:02 AM, Jon Elson via cctalk wrote:
Remember that ARM licenses it?s ISA as well as implementations.
Some ARM licenses, do their own implementations and those *are*
microcoded.
There are a number of reasons for doing micro-code and a number
of architectures use it especially if the micro-code can be ?patched?
(which AFAIK they all do now) to allow for fixing ?bugs? once the
chip has been released. If the bug is severe enough (remember the
DIV bug in the early 80286?) to have a recall done then the overhead
of having patchable micro-code will pay for itself many fold.
It is also important to note, that today?s CPUs are not just a bare
CPU implementing an ISA. They are embedded in an SoC with
potentially many other micro-controllers/CPUs that are not visible
to the programmer and those are all ?micro-coded? and control
various aspects of the SoC. The last SoC that I worked on had
(in addition to the 8 ARM application CPUs which are micro-coded
BTW) has over 12 other micro-controllers (mostly ARM R5s)and
4 VLIW DSPs (not to mention several megabytes of SRAM that
is outside of the various caches). After all you have to do something
with 7 *billion* transistors. ;-)
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.
TTFN - Guy
Random logic instruction decode was a REAL issue
in about 1960 - 1965,
when computers were built with discrete transistors. The IBM 7092, for
instance, had 55,000 transistors on 11,000 circuit boards. I don't know
how much of that was instruction decode, but I'll guess that a fair bit
was. The IBM 360's benefited from microcode, allowing them to have a
much more complex and orthogonal instruction set with less logic.
But, once ICs were available, the control logic was less of a problem.
But, microcode still made sense, as memory was so slow that performance
was dictated by memory cycle time, and the microced did not slow the
system down. Once fast cache became standard, then eliminating
performance bottlenecks became important. And, once we went from lots
of SSI chips to implement a CPU to one big chip, then it was possible to
implement the control logic within the CPU chip efficiently.
I don't know--"microcode" in today's world is a very slippery term.
If
you're talking about vertical microcode, then I'm inclined to agree with
you. But even ARM, which is held up as the golden example of
microcode-less CPU design, is programmed via HDL, which is then compiled
into a hardware design, at least in instruction decoding. So ARM is a
programmed implementation. I suspect that if x86 microcode were to be
written out in HDL and compiled, Intel could make the same claim.
I think of it as being akin to "interpreted" vs. "compiled"
languages--the boundary can be rather fuzzy (e.g. "tokenizing",
"p-code", "incremental compilation"... etc.)
11:31 a.m.
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.
While this results in a great many instructions, many were used little.
It's hard to grasp that the same guy who designed the CDC 6400 (a RISC
architecture) also designed the STAR-100.
It's worth noting that all 256 8-bit opcodes are used; many are modified
by another 8-bit modifier quantity whose meaning varies greatly. In
effect, you have something closer to 1000 distinct instructions, if not
more.
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?
Subsequent embodiments of the architecture dropped a great many
microcoded instructions, with, as far as I can tell, no deleterious effect.
The manual for the STAR-100 hardware description is on bitsavers under
cdc/cyber/cyber_200 if you're curious.
Some earlier computers implemented additional instructions by
hard-coding subroutines whose entry address was determined by the
op-code of the instruction. Macro-coding, if you will.
--Chuck
11:37 a.m.
On Jan 2, 2019, at 2:31 PM, Chuck Guzis via cctalk
<cctalk at classiccmp.org> wrote:
On 1/2/19 10:44 AM, Guy Sotomayor Jr wrote:
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.
paul
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? 
12:09 p.m.
On Wed, Jan 02, 2019 at 02:37:44PM -0500, Paul Koning via cctalk wrote:
Which then reminds me further of the Coldfire processor which
*did* remove the more complex instructions from the chip!
On Jan 2, 2019, at 2:31 PM, Chuck Guzis via
cctalk <cctalk at classiccmp.org> wrote:
On 1/2/19 10:44 AM, Guy Sotomayor Jr wrote:
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. 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?
paul
Diane
--
- db at FreeBSD.org db at db.net http://artemis.db.net/~db
3:12 p.m.
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-bounces at classiccmp.org> on behalf of Diane Bruce via cctalk
<cctalk at 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:
Which then reminds me further of the Coldfire processor which
*did* remove the more complex instructions from the chip!
On Jan 2, 2019, at 2:31 PM, Chuck Guzis via
cctalk <cctalk at classiccmp.org> wrote:
On 1/2/19 10:44 AM, Guy Sotomayor Jr wrote:
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. 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?
paul
Diane
--
- db at FreeBSD.org db at db.net http://artemis.db.net/~db
3:42 p.m.
On Wed, Jan 2, 2019 at 4:12 PM dwight via cctalk <cctalk at classiccmp.org>
wrote:
I thought I'd note that the divide problem
couldn't have been patched
with a micro code patch.
If you're talking about the Pentium FDIV bug, present on the early 80501
chips (60 and 66 MHz) and 80502 chips (75, 90, and 100 MHz), they weren't
able to fix that with a microcode patch. They actually issued a recall for
those chips.
However, Intel has successfully fixed other bugs using microcode patches,
including some but not all of the recent speculative execution side channel
problems (Meltdown and Spectre). They have also used microcode patches to
disable instructions that were broken and couldn't be fixed by microcode,
including the TSX-NI instructions of some Haswell, broadwell, and Skylake
CPUs.
8:12 p.m.
I believe that is the one. Intel tried to say it wasn't an issue until it was shown
that the error was significant when using floating point numbers near integer values. I
suspect that the fellow that forgot to include the mask file for that ROM got a bad
review.
Dwight
________________________________
From: Eric Smith <spacewar at gmail.com>
Sent: Wednesday, January 2, 2019 3:42 PM
To: dwight; General Discussion: On-Topic and Off-Topic Posts
Subject: Re: Microcode, which is a no-go for modern designs
On Wed, Jan 2, 2019 at 4:12 PM dwight via cctalk <cctalk at
classiccmp.org<mailto:cctalk at classiccmp.org>> wrote:
I thought I'd note that the divide problem couldn't have been patched with a
micro code patch.
If you're talking about the Pentium FDIV bug, present on the early 80501 chips (60 and
66 MHz) and 80502 chips (75, 90, and 100 MHz), they weren't able to fix that with a
microcode patch. They actually issued a recall for those chips.
However, Intel has successfully fixed other bugs using microcode patches, including some
but not all of the recent speculative execution side channel problems (Meltdown and
Spectre). They have also used microcode patches to disable instructions that were broken
and couldn't be fixed by microcode, including the TSX-NI instructions of some Haswell,
broadwell, and Skylake CPUs.
3 Jan
3 Jan
11:52 p.m.
On Wed, Jan 2, 2019 at 9:12 PM dwight via cctalk <cctalk at classiccmp.org>
wrote:
I believe that is the one. Intel tried to say it
wasn't an issue until it
was shown that the error was significant when using floating point numbers
near integer values. I suspect that the fellow that forgot to include the
mask file for that ROM got a bad review.
The majority of the ROM contents were present. Apparently five entries were
missing.
http://www.verifsudha.com/2017/09/11/pentium-fdiv-bug-curious-engineer/
11:55 p.m.
And the original analysis paper, "It Takes Six Ones to Reach a Flaw":
http://www.acsel-lab.com/arithmetic/arith12/papers/ARITH12_Coe.pdf
4 Jan
4 Jan
7:08 a.m.
May ability to understand these papers is somewhat limited. If I understand correctly the
following.
Most divide routines that I've seen allow the remainder to be 1,0,-1 relative to the
normal remainder. The answer will converge as the error of the remainder never leaves this
range.
In the case of the pentium, the remainder is 2,1,0,-1,-2. This allows the division to
converge on the answer quicker. The error was that if the remainder was right on one edge
it would eventually fall of the edge and not converge. From the paper, that would be the 5
1's in a row, of the divisor.
At least that is my understanding. It is to early in the morning for me.
Dwight
________________________________
From: Eric Smith <spacewar at gmail.com>
Sent: Thursday, January 3, 2019 11:55 PM
To: dwight; General Discussion: On-Topic and Off-Topic Posts
Subject: Re: Microcode, which is a no-go for modern designs
And the original analysis paper, "It Takes Six Ones to Reach a Flaw":
http://www.acsel-lab.com/arithmetic/arith12/papers/ARITH12_Coe.pdf
2:21 p.m.
On Fri, Jan 4, 2019 at 8:08 AM dwight via cctalk <cctalk at classiccmp.org>
wrote:
May ability to understand these papers is somewhat
limited. If I
understand correctly the following.
Most divide routines that I've seen allow the remainder to be 1,0,-1
relative to the normal remainder. The answer will converge as the error of
the remainder never leaves this range.
In the case of the pentium, the remainder is 2,1,0,-1,-2. This allows the
division to converge on the answer quicker. The error was that if the
remainder was right on one edge it would eventually fall of the edge and
not converge. From the paper, that would be the 5 1's in a row, of the
divisor.
My interpretation is that with the five table entries with the wrong
values, it always converges, but for some input values it converges to the
wrong answer. I could be wrong, though.
In any case, I'm sure there were a lot of people at Intel that were unhappy
that they couldn't patch this with a microcode fix or workaround. Although
Intel relented and offered to replace ALL affected Pentiums, apparently a
substantial number of the buggy ones were never sent in.
2179
days inactive
2181
days old
14 comments
8 participants
participants (8)
-
cclist＠sydex.com -
db＠db.net -
dkelvey＠hotmail.com -
elson＠pico-systems.com -
ggs＠shiresoft.com -
paulkoning＠comcast.net -
pbirkel＠gmail.com -
spacewar＠gmail.com