Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.arch > #1698 > unrolled thread

Re: Beyond binary compatibility

Back to article view | Back to comp.arch

Contents

  Re: Beyond binary compatibility "Paul A. Clayton" <paaronclayton@gmail.com> - 2011-05-19 12:54 -0700
    Re: Beyond binary compatibility timcaffrey@aol.com (Tim McCaffrey) - 2011-05-19 21:06 +0000
    Re: Beyond binary compatibility "Ken Hagan" <k.hagan@thermoteknix.com> - 2011-05-20 14:12 +0100
      Re: Beyond binary compatibility "Paul A. Clayton" <paaronclayton@gmail.com> - 2011-06-06 23:32 -0700
        Re: Beyond binary compatibility MitchAlsup <MitchAlsup@aol.com> - 2011-06-07 08:31 -0700
          Re: Beyond binary compatibility "Paul A. Clayton" <paaronclayton@gmail.com> - 2011-06-07 14:58 -0700
        Re: Beyond binary compatibility "Ken Hagan" <k.hagan@thermoteknix.com> - 2011-06-08 10:05 +0100
          Re: Beyond binary compatibility torbenm@diku.dk (Torben Ægidius Mogensen) - 2011-06-10 16:00 +0200
    Re: Beyond binary compatibility torbenm@diku.dk (Torben Ægidius Mogensen) - 2011-05-23 10:31 +0200
    Re: Beyond binary compatibility Morten Reistad <first@last.name> - 2011-05-29 10:06 +0200
      Re: Beyond binary compatibility George Neuner <gneuner2@comcast.net> - 2011-05-31 12:41 -0400
    Re: Beyond binary compatibility MitchAlsup <MitchAlsup@aol.com> - 2011-05-29 13:20 -0700
      Re: Beyond binary compatibility "Paul A. Clayton" <paaronclayton@gmail.com> - 2011-06-07 00:05 -0700
        Re: Beyond binary compatibility MitchAlsup <MitchAlsup@aol.com> - 2011-06-07 08:22 -0700
          Re: Beyond binary compatibility "Paul A. Clayton" <paaronclayton@gmail.com> - 2011-06-07 15:02 -0700
            Re: Beyond binary compatibility MitchAlsup <MitchAlsup@aol.com> - 2011-06-08 08:41 -0700
            Re: Beyond binary compatibility "Andy \"Krazy\" Glew" <andy@SPAM.comp-arch.net> - 2011-06-11 09:31 -0700

#1698 — Re: Beyond binary compatibility

On Thursday, May 19, 2011 12:40:58 PM UTC-4, MitchAlsup wrote:
> With respect; actual compatability will sell lots more chips that
> almost compatability. If for no other reason that Fear Uncertanty and
> Doubt.

Even for an immediate conversion, I think _Intel_ could 
provide a slightly incompatible ISA while only losing a 
tiny amount of sales.  (AMD might be able to find some 
DOS program that uses self-modifying code that breaks 
the binary translation mechanism--in terms of correctness--
and several examples of code that have huge performance 
penalties--e.g., half speed.  However, such might not be 
enough to significantly dent Intel's brand strength.)

Providing a transition path with the stated deprecation 
of features and tools to update software might allow 
substantial changes.  E.g., providing 80-bit FP in AVX/
SSE could significantly ease the deprecation of x87.

Even without the external FUD, Intel has significant 
reasons not to seek an x86 clean-up.  A not insignificant 
barrier to competition for Intel x86 is probably the 
validation tools and in-house familiarity with the 
quirks of x86.  (A much cleaner x86-derived ISA could 
also be more friendly to binary translation, so the 
barrier to providing software compatibility on an alien 
ISA would be reduced, reducing the special value of x86.)

Another compatibility story is IBM zSeries (mainframe).
While IBM controls the underlying software and so 
could more easily introduce a binary translation layer, 
its zSeries customers are probably MUCH more 
risk-averse/FUD-susceptible and a separate chip line 
provides a differentiating factor that can facilitate 
even higher margins.  (Producing incompatible POWER 
processors is probably more acceptable, but such may 
not seem as worthwhile.)

Compatibility by software translation also introduces 
licensing and support issues.  Binary translation 
might technically violate the software licensing 
agreement.  In addition, it would be very tempting 
for software vendors to claim that a bug is a result 
of a bug in the compatibility layer not in their 
software.  It would generally be impractical to 
keep a compatible machine to replicate the bug 
(especially if the bug depends on race conditions or 
the size of the data set which the old machine could 
not replicate).

The x86 transition to 64-bits was probably a rare 
opportunity to substantially change x86.  
Unfortunately, AMD did not have enough clout (or 
design resources?) to make a more radical change 
and I suspect that Microsoft put significant 
pressure on AMD to minimize the OS-level changes 
that would be required.

Some adjustments could also greatly ease later 
changes.  E.g., providing an obvious annotation 
of writes into code space could make later changes 
significantly easier (as well as probably 
simplifying support for JIT compilation).

I wish (but by no means expect) that ARM, MIPS, and 
Power.org could join forces and form the Post-RISC 
Consortium that would develop an ISA (or family of 
closely related ISAs) which would be open to 
outside implementation and extension.  The different 
organizations could target different workloads, 
different strengths of software development tools, 
and different licensing styles.  Of course, such 
would introduce an open market--rather than several 
somewhat separated markets--which reduces profit 
margins (which is unattractive even if the total 
profit increased from customers being less reluctant 
to buy a product with less lock-in and the benefits 
of network effects).

Realistically, even if a PRC was formed, the ISA 
would probably have enough design-by-committee 
defects to make it worse than any of the alternatives.
I would still like to dream that such a limited form 
of "world peace" could be accomplished, even if I 
'know' that it is more likely that I will be hired by 
Intel to work on the next x86 microarchitecture (a 
probability that is not defined as zero and may even 
be greater than the probability that a black hole 
will pass within 1 AU of the sun within the next 20 
years--or not).

[toc] | [next] | [standalone]

#1704

In article 
<cac3b264-37f3-4f29-881d-7a37c8f90d2f@glegroupsg2000goo.googlegroups.c
om>, paaronclayton@gmail.com says...
>
>The x86 transition to 64-bits was probably a rare 
>opportunity to substantially change x86.  
>Unfortunately, AMD did not have enough clout (or 
>design resources?) to make a more radical change 
>and I suspect that Microsoft put significant 
>pressure on AMD to minimize the OS-level changes 
>that would be required.
>
Yes, I agree, AMD could have created a new instruction set that was 
substantially more efficient.  The excuse that they did what they did 
to make code generators easier to write is a red-herring (or a basic 
lack of understanding of code generators on the part of the 
designers).  I wrote a code generator for x64 (starting from an x86 
code generator) and by the time I got done I might as well have 
started from scratch.  Note that you can create an instruction set 
that has essentially the same semantics, just a more efficient 
encoding.  Adding support for things like 48 bit offsets and 64 bit 
immediates would be nice  :) .

Even today, AMD and/or Intel could introduce a new instruction set 
that is just a recoding of the presently available instructions and 
put another instruction decoder on the chip (like ARM/Thumb).  Won't 
happen.

Oh well, back to work...

		- Tim

[toc] | [prev] | [next] | [standalone]

#1742

On Thu, 19 May 2011 20:54:36 +0100, Paul A. Clayton  
<paaronclayton@gmail.com> wrote:

> (A much cleaner x86-derived ISA could
> also be more friendly to binary translation, so the
> barrier to providing software compatibility on an alien
> ISA would be reduced, reducing the special value of x86.)

We had FX!32 a decade or more ago, specifically targetting the x86 ISA,
so I don't think the objections to translation are technical ones.
You mention a couple yourself...

> Compatibility by software translation also introduces
> licensing and support issues.  Binary translation
> might technically violate the software licensing
> agreement.  In addition, it would be very tempting
> for software vendors to claim that a bug is a result
> of a bug in the compatibility layer not in their software.

...and I'd add the fact that x86 just isn't bad enough. Not enough people  
feel a need to risk migrating and so the rival hardware doesn't get the  
economics of scale, so it ends up being twice the price.

[toc] | [prev] | [next] | [standalone]

#2080

On May 20, 9:12 am, "Ken Hagan" <k.ha...@thermoteknix.com> wrote:
> On Thu, 19 May 2011 20:54:36 +0100, Paul A. Clayton  
>
> <paaronclay...@gmail.com> wrote:
> > (A much cleaner x86-derived ISA could
> > also be more friendly to binary translation, so the
> > barrier to providing software compatibility on an alien
> > ISA would be reduced, reducing the special value of x86.)
>
> We had FX!32 a decade or more ago, specifically targetting the x86 ISA,
> so I don't think the objections to translation are technical ones.
> You mention a couple yourself...

I was under the impression that FX!32 was meant to provide adequate
performance on 'desktop' applications on workstation hardware, not
to actually provide 99+% of native performance.  (Of course, a
dynamic system could perform some feedback-directed optimization.)

> > Compatibility by software translation also introduces
> > licensing and support issues.  Binary translation
> > might technically violate the software licensing
> > agreement.  In addition, it would be very tempting
> > for software vendors to claim that a bug is a result
> > of a bug in the compatibility layer not in their software.
>
> ...and I'd add the fact that x86 just isn't bad enough. Not enough people  
> feel a need to risk migrating and so the rival hardware doesn't get the  
> economics of scale, so it ends up being twice the price.

I agree.  At the high-performance end, x86-64 might have less than
a 10% penalty relative to an _ideal_ ISA.  (In an article about
ARM servers, someone from Microsoft was quoted as saying a 2x
advantage would be necessary to justify a transition.  It is hard
to imagine that such an extreme difference would be necessary, but
such would be difficult to achieve from Architectural advantages
especially against Intel's process and design resource advantages.)
At the low-performance end, x86-64 might have a larger penalty.

[toc] | [prev] | [next] | [standalone]

#2099

On Jun 7, 1:32 am, "Paul A. Clayton" <paaronclay...@gmail.com> wrote:
> At the low-performance end, x86-64 might have a larger penalty.

Only if you end up comparing a 32-bit ARM against a 64-bit x86.

By the time both machines are 64-bits, both low end implementations
will be within 20% of each other in size.
If one chopped x86 back to 32-bits and did a modern low end
implementation on that architecture, it too would be area competitive
with a low end ARM (i.e less than 20% area penalty).

Mitch

P.S. If any company wants to understand how, give me a call, we can
work something out.

[toc] | [prev] | [next] | [standalone]

#2102

On Jun 7, 11:31 am, MitchAlsup <MitchAl...@aol.com> wrote:
> On Jun 7, 1:32 am, "Paul A. Clayton" <paaronclay...@gmail.com> wrote:
>
> > At the low-performance end, x86-64 might have a larger penalty.
>
> Only if you end up comparing a 32-bit ARM against a 64-bit x86.
>
> By the time both machines are 64-bits, both low end implementations
> will be within 20% of each other in size.
> If one chopped x86 back to 32-bits and did a modern low end
> implementation on that architecture, it too would be area competitive
> with a low end ARM (i.e less than 20% area penalty).

"less than 20% area penalty" is a larger penalty than my stated
'less than 10%' penalty for a high-performance implementation
relative to an _ideal_ Architecture--and ARM is not an ideal
Architecture for the low-end or the high-end (though its deviance
from the ideal may have minimal consequence, perhaps).

While a 15% area difference would not compensate for even a half
node difference in process technology (and core size would likely
be much less important on a feature-rich SoC and would have an
even lower impact on system cost [I seem to recall that the
processor and chipset cost {not price} for a desktop was perhaps
less than 10% of the system cost]), it seems like a large number
to me.  (The cost impact may be so small that it would probably
not be reflected in the system price since the system price would
be marketed for psychological impact--e.g., a 99.99 monetary unit
item is perceived as much less expensive than a 101.00 monetary
unit item.)

> Mitch
>
> P.S. If any company wants to understand how, give me a call, we can
> work something out.

[toc] | [prev] | [next] | [standalone]

#2106

On Tue, 07 Jun 2011 07:32:29 +0100, Paul A. Clayton  
<paaronclayton@gmail.com> wrote:

> I was under the impression that FX!32 was meant to provide adequate
> performance on 'desktop' applications on workstation hardware, not
> to actually provide 99+% of native performance.  (Of course, a
> dynamic system could perform some feedback-directed optimization.)

I think that is correct, but it has certainly been claimed here that FX!32  
on Alpha hardware could outrun the in-order Pentiums of the day, so we're  
presumably talking about a performance percentage rather than a factor.

And of course, the OS and its freebie apps were native, so that's the  
GooTube generation covered already.

> (In an article about
> ARM servers, someone from Microsoft was quoted as saying a 2x
> advantage would be necessary to justify a transition.  It is hard
> to imagine that such an extreme difference would be necessary, but
> such would be difficult to achieve from Architectural advantages

I think 2x is a conservative estimate.

These days, a lot of PC applications are written in languages that achieve  
less than half the native performance. Google put out a comparison paper  
recently, pitching C++ against Java, Scala and Go. Both with and without  
serious optimisation effort, the C++ versions outran the competition by a  
factor of more than 2. But this is not an advert for C++ because in  
practice users tolerate applications written in these other languages.  
Such apps would obviously not experience an *additional* drop in  
performance if they were JIT-ed to ARM rather than x86. They'd run at the  
same speed. They'd be equally tolerated.

Also, nearly all PC users are not running on machines whose performance is  
within 2x of the best that you can buy. There's not just tolerance, but  
actual /demand/ out there for machines that are slower by a factor of  
"several", as long as they have a compensating benefit, like "half the  
price" or "battery lasts all day". Because of the costs and power  
consumption of the rest of the system, ARM machines probably can't quite  
manage either of those benefits over x86 yet, but the market demand will  
be there if they ever do.

[toc] | [prev] | [next] | [standalone]

#2126

"Ken Hagan" <k.hagan@thermoteknix.com> writes:


> Also, nearly all PC users are not running on machines whose
> performance is within 2x of the best that you can buy. There's not
> just tolerance, but  actual /demand/ out there for machines that are
> slower by a factor of  "several", as long as they have a compensating
> benefit, like "half the  price" or "battery lasts all day". Because of
> the costs and power  consumption of the rest of the system, ARM
> machines probably can't quite  manage either of those benefits over
> x86 yet, but the market demand will  be there if they ever do.

System price and power usage (at a given performance point) is to a
large degree determined by how much of what you need you can put on a
single chip.  ARM SOCs tend to have more on them than x86 ditto, and
since there is a much wider selection of diffrent SoCs for ARM, it is
more likely that you can find one that doesn't have too many superfluous
features (for your application) while having all that you need.

Note that this is not so much a feature of the processor cores but more
on differences in market models: ARM licenses their cores to anyone who
would put them on SoCs, while Intel doesn't, so you have to make do with
the SoCs that Intel provide if you want Intel cores.  Intel could do the
same as ARM, and there are signs that they are, at least, becoming more
open to producing x86 SoCs to user specifications -- as long as the user
is big enough and willing to pay enough.

	Torben

[toc] | [prev] | [next] | [standalone]

#1780

"Paul A. Clayton" <paaronclayton@gmail.com> writes:


> I wish (but by no means expect) that ARM, MIPS, and Power.org could
> join forces and form the Post-RISC Consortium that would develop an
> ISA (or family of closely related ISAs) which would be open to outside
> implementation and extension.
>
> Realistically, even if a PRC was formed, the ISA would probably have
> enough design-by-committee defects to make it worse than any of the
> alternatives.

Indeed.  Design by committee is rarely a good idea unless all agree to
keep KISS as their main focus.  And even then only if the committee
isn't too large.

In any case, I doubt there would be that much value in unifying ISAs as
long as there is no similar unification of coprocessors (graphics,
sound, signal processing, etc.).  Porting to another system is still be
a major effort if you have to translate all the coprocessor code.

	Torben

[toc] | [prev] | [next] | [standalone]

#1933

In article <cac3b264-37f3-4f29-881d-7a37c8f90d2f@glegroupsg2000goo.googlegroups.com>,
Paul A. Clayton <comp.arch@googlegroups.com> wrote:
>On Thursday, May 19, 2011 12:40:58 PM UTC-4, MitchAlsup wrote:

>I wish (but by no means expect) that ARM, MIPS, and 
>Power.org could join forces and form the Post-RISC 
>Consortium that would develop an ISA (or family of 
>closely related ISAs) which would be open to 
>outside implementation and extension.  The different 
>organizations could target different workloads, 
>different strengths of software development tools, 
>and different licensing styles.  Of course, such 
>would introduce an open market--rather than several 
>somewhat separated markets--which reduces profit 
>margins (which is unattractive even if the total 
>profit increased from customers being less reluctant 
>to buy a product with less lock-in and the benefits 
>of network effects).

Why not go for an intermediate code standard, where
we keep the compiler information to generate code, but
the code can be interpreted as-is; or compiled properly
to the ISA in question. 

Even the various x86 varietes have sufficiently different
performance and ISA variations for this to seem sensible.

>Realistically, even if a PRC was formed, the ISA 
>would probably have enough design-by-committee 
>defects to make it worse than any of the alternatives.
>I would still like to dream that such a limited form 
>of "world peace" could be accomplished, even if I 
>'know' that it is more likely that I will be hired by 
>Intel to work on the next x86 microarchitecture (a 
>probability that is not defined as zero and may even 
>be greater than the probability that a black hole 
>will pass within 1 AU of the sun within the next 20 
>years--or not).

A software format does not require the same level
of involvment by the big corporations.

But, on the other hand, the Open Source environments
have managed to keep up with a large number of
architectures without too much hassle, all things
considered. 

-- mrr

[toc] | [prev] | [next] | [standalone]

#1969

On Sun, 29 May 2011 10:06:16 +0200, Morten Reistad <first@last.name>
wrote:

>In article <cac3b264-37f3-4f29-881d-7a37c8f90d2f@glegroupsg2000goo.googlegroups.com>,
>Paul A. Clayton <comp.arch@googlegroups.com> wrote:
>>On Thursday, May 19, 2011 12:40:58 PM UTC-4, MitchAlsup wrote:
>
>>I wish (but by no means expect) that ARM, MIPS, and 
>>Power.org could join forces and form the Post-RISC 
>>Consortium that would develop an ISA (or family of 
>>closely related ISAs) which would be open to 
>>outside implementation and extension.  The different 
>>organizations could target different workloads, 
>>different strengths of software development tools, 
>>and different licensing styles.  Of course, such 
>>would introduce an open market--rather than several 
>>somewhat separated markets--which reduces profit 
>>margins (which is unattractive even if the total 
>>profit increased from customers being less reluctant 
>>to buy a product with less lock-in and the benefits 
>>of network effects).
>
>Why not go for an intermediate code standard, where
>we keep the compiler information to generate code, but
>the code can be interpreted as-is; or compiled properly
>to the ISA in question. 
>
>Even the various x86 varietes have sufficiently different
>performance and ISA variations for this to seem sensible.

The compiler information is, in general, many times larger than the
eventual generated code - 10..50x depending on what analyses have been
performed - and serializing the data for multiplatform use would make
it even larger.  It might make some sense to use as a distribution
format to be natively compiled on installation, but to accommodate JIT
or interpretation, I believe that a more suitable IR format would need
to be adopted ... a lot of what compilers produce internally is
consumed serially and really isn't structured to accommodate the more
randomized needs of a JIT compiler or interpreter.

There are a handful of AST based distribution formats that retain
structure and semantics much better than byte code and are suitable
for JIT or interpretation, but as yet they haven't seen any wide-scale
adoption.  AST formats are quite a bit larger than byte code (though
still much smaller than compiler IR) and their size has been seen as a
negative for, e.g., web applications.

>-- mrr

George

[toc] | [prev] | [next] | [standalone]

#1937

On May 19, 2:54 pm, "Paul A. Clayton" <paaronclay...@gmail.com> wrote:

> Even without the external FUD, Intel has significant
> reasons not to seek an x86 clean-up.  A not insignificant
> barrier to competition for Intel x86 is probably the
> validation tools and in-house familiarity with the
> quirks of x86.  

Once the x86 got to the same performance levels as the RICK chips,
there was no useful reason to fix the architecture. (i.e. not broke,
don't fix)


> The x86 transition to 64-bits was probably a rare
> opportunity to substantially change x86.  
> Unfortunately, AMD did not have enough clout (or
> design resources?) to make a more radical change
> and I suspect that Microsoft put significant
> pressure on AMD to minimize the OS-level changes
> that would be required.

 While AMD had marginal clout, the ISA changes were actually blessed
by MS. In addition there was a proposal inside Intel that looked and
smelled almost like AMD's version. So at lest two design teams
designed almost the same thing (again).

But you guys are missing the biggest reason to leave the architecture
pretty much as it is. Once you have the instruction cache/buffer
shipping instructions to the decoder, it is very hard (wires and
gates) to justify sending them to something that is significantly
different. At the microarchitectural level (and especially with the
microcode ROM being a big protion of the decoder footprint, there is
every reason inthe book to make the two odes as close as possible.

In addition, only those who have never built an x86 decoder retain the
notion that x86 needs to be significantly changed. Look, guys (and
gals) x86 is not that irregualr once you get your head around the
concept that there are over 1000 instructions in the architecture
(before the 32->64 transistion). More if you consider all the MSR
stuff and CPUID stuff as independent instructions.

Mitch

[toc] | [prev] | [next] | [standalone]

#2081

On May 29, 4:20 pm, MitchAlsup <MitchAl...@aol.com> wrote:
[snip]
> But you guys are missing the biggest reason to leave the architecture
> pretty much as it is. Once you have the instruction cache/buffer
> shipping instructions to the decoder, it is very hard (wires and
> gates) to justify sending them to something that is significantly
> different. At the microarchitectural level (and especially with the
> microcode ROM being a big protion of the decoder footprint, there is
> every reason inthe book to make the two odes as close as possible.

Would it not be practical to have predecode logic between L2
and the instruction cache that would slightly modify the new
ISA and more substantially modify x86 code?

Because instructions can cross cache block boundaries, it
might not be easy even to reclaim some prefix sequences by
requiring a single ordering of prefixes.  (I am under the
impression that some flexibility in prefix ordering is
allowed by x86, but I may be mistaken.)

In addition, with support of system software for at least
limited binary translation, a more extreme change might be
practical.

With respect to microcode, how much of the microcode is
merely instruction ROM and how much uses specialized state
machines (in the front-end)?  I am also curious about how
much of the microcode could be shared among cores on the
same chip or even put into main memory.  (ISTR that one
of Mitch's previous posts mentioned that a tiny core CMP
x86 could share a large fraction of the microcode.)

> In addition, only those who have never built an x86 decoder retain the
> notion that x86 needs to be significantly changed. Look, guys (and
> gals) x86 is not that irregualr once you get your head around the
> concept that there are over 1000 instructions in the architecture
> (before the 32->64 transistion). More if you consider all the MSR
> stuff and CPUID stuff as independent instructions.

Is this mostly an indication of greater experience (knowing
special tricks compared to the more nearly brain-dead simple
decoding of Alpha) and better tools?  From my very limited
exposure, Thumb2 seems likely to be significnatly easier to
decode than x86--and Thumb2 is not an encoding optimized for
easy decode under the constraint of good code density.  (The
If-Then and Load/Store Multiple instructions--which use bit
vectors in a way that would increase decode complexity, it
seems--might push Thumb2 very near x86 in decode complexity.)

x86 decode complexity is probably largely orthogonal to the
rest of the implementation (i.e., more nearly additive
complexity than multiplicative complexity), which also
reduces the impact of the complexity.

[toc] | [prev] | [next] | [standalone]

#2097

On Jun 7, 2:05 am, "Paul A. Clayton" <paaronclay...@gmail.com> wrote:
> With respect to microcode, how much of the microcode is
> merely instruction ROM and how much uses specialized state
> machines (in the front-end)?

Back in the early days of Opteron with 3K microcode 'words' about 1/2
was used for power on initialization and power on checks and never
used again. The Virtual machine Opterons have 4K microcode words and
about 1/3 of it ends up "used once".

>                                         I am also curious about how
> much of the microcode could be shared among cores on the
> same chip or even put into main memory.  (ISTR that one
> of Mitch's previous posts mentioned that a tiny core CMP
> x86 could share a large fraction of the microcode.)

If you are willing to suffer just under 1% performance degredation,
the local-CPU microcode store only needs about 500 words to
efficiently execute Zen, Windows, Linux operating systems and their
applications. This allows up to 3.5K words to be shared amoungst all
the on-die CPUs.

> > In addition, only those who have never built an x86 decoder retain the
> > notion that x86 needs to be significantly changed. Look, guys (and
> > gals) x86 is not that irregualr once you get your head around the
> > concept that there are over 1000 instructions in the architecture
> > (before the 32->64 transistion). More if you consider all the MSR
> > stuff and CPUID stuff as independent instructions.
>
> Is this mostly an indication of greater experience (knowing
> special tricks compared to the more nearly brain-dead simple
> decoding of Alpha) and better tools?

No, its mostly from grinding through the decode logic until you see
the larger scale patterns, finding some way of articulating the large
scale patterns and redoing the logic based on this new organizing
principle. {Somewhat like taking a wallace tree multiplier and
converting it into a 4-2 compresser tree multiplier. All the same and
all different at the same time.}

Mitch

[toc] | [prev] | [next] | [standalone]

#2103

On Jun 7, 11:22 am, MitchAlsup <MitchAl...@aol.com> wrote:
> On Jun 7, 2:05 am, "Paul A. Clayton" <paaronclay...@gmail.com> wrote:
>
> > With respect to microcode, how much of the microcode is
> > merely instruction ROM and how much uses specialized state
> > machines (in the front-end)?
>
> Back in the early days of Opteron with 3K microcode 'words' about 1/2
> was used for power on initialization and power on checks and never
> used again. The Virtual machine Opterons have 4K microcode words and
> about 1/3 of it ends up "used once".

So there are no front-end state machines for generating
microcode?  (It seemed like something like FXSAVE might use
a state machine to iterate through the register names.)

> >                                         I am also curious about how
> > much of the microcode could be shared among cores on the
> > same chip or even put into main memory.  (ISTR that one
> > of Mitch's previous posts mentioned that a tiny core CMP
> > x86 could share a large fraction of the microcode.)
>
> If you are willing to suffer just under 1% performance degredation,
> the local-CPU microcode store only needs about 500 words to
> efficiently execute Zen, Windows, Linux operating systems and their
> applications. This allows up to 3.5K words to be shared amoungst all
> the on-die CPUs.

Neat.  Thank you for the information.

[toc] | [prev] | [next] | [standalone]

#2108

On Jun 7, 5:02 pm, "Paul A. Clayton" <paaronclay...@gmail.com> wrote:
> On Jun 7, 11:22 am, MitchAlsup <MitchAl...@aol.com> wrote:
> > Back in the early days of Opteron with 3K microcode 'words' about 1/2
> > was used for power on initialization and power on checks and never
> > used again. The Virtual machine Opterons have 4K microcode words and
> > about 1/3 of it ends up "used once".
>
> So there are no front-end state machines for generating
> microcode?  (It seemed like something like FXSAVE might use
> a state machine to iterate through the register names.)

Nope, just a series of stores in a sequential µCode routine.

Mitch

[toc] | [prev] | [next] | [standalone]

#2146

On 6/7/2011 3:02 PM, Paul A. Clayton wrote:
> On Jun 7, 11:22 am, MitchAlsup<MitchAl...@aol.com>  wrote:
>> On Jun 7, 2:05 am, "Paul A. Clayton"<paaronclay...@gmail.com>  wrote:
>>
>>> With respect to microcode, how much of the microcode is
>>> merely instruction ROM and how much uses specialized state
>>> machines (in the front-end)?
>>
>> Back in the early days of Opteron with 3K microcode 'words' about 1/2
>> was used for power on initialization and power on checks and never
>> used again. The Virtual machine Opterons have 4K microcode words and
>> about 1/3 of it ends up "used once".
>
> So there are no front-end state machines for generating
> microcode?  (It seemed like something like FXSAVE might use
> a state machine to iterate through the register names.)

No. There are no front end state machines.  Possibly just a microcode 
loop counter, but  that is supporting generic microcode.

I advocate state machine support for REP MOVS, etc., but that requires 
information from execution - the loop count - so it is not purely a 
front end state machine.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.arch

csiph-web