Re: IBM 45nm -- new or licensed from Intel?


"Anton Ertl" <anton@xxxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message news:2008Feb18.200421@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx
"Wilco Dijkstra" <Wilco_dot_Dijkstra@xxxxxxxxxxxx> writes:

"Anton Ertl" <anton@xxxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message news:2008Feb14.202346@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx
"Wilco Dijkstra" <Wilco_dot_Dijkstra@xxxxxxxxxxxx> writes:
...
But it's not just the encoding that is irregular, it is the odd register
set and instructions that act on them. Think of the weird set of 8, 16, 32
and 64-bit registers

AMD64 has 16 64-bit general-purpose registers, of which the lower 8
bits, 16 bits, or 32 bits can be used, just as in most other register
machines. Why do you think they are weird? Ok, there's also AL BL CL
DL, but there is no requirement to use them. For IA-32, the 8-bit
registers are more restricted, but you do not need to use them (see
below).

And AH, BH, CH, DH, AX, BX, CX and DX. Sure, you don't have to use
them (and things get a lot easier if you don't) but many x86 compilers
(and at least one x64 compiler) do so.

(and the complex stalls to avoid if you do use the
narrow registers)

That's not an ISA issue. And if you program like on RISCs (i.e., load
with MOVSX or MOVZX), that's not an issue at all. And it also solves
the IA-32 8-bit register issue.

Absolutely. And it avoids the register allocation complexity (packing
8 and 16-bit operations optimally in the set of available registers).

the hard coded registers in common instructions etc.

The only ones I can think of are CALL, RET, PUSH, POP, and most code
generators would not use any other register than ESP for these
instructions (especially CALL) even if they had the option.

It's good for codesize to use a hard coded stack pointer/link register,
so you see this on modern RISCs as well.

All other hard-coded things are for not-so-common instructions like
shifts and division.

And there is multiply of course.

The decision on the encoding of constants was performed by the C
compiler which generated the snippets. However, the constant-pool
approach would add more complexity than the constant-splitting
approach: my compiler would have to find out that the snippet refers
to a constant pool, where the offset into the constant pool is, set up
its own constant pool, patch the offset, and support dealing with
constant pools that cannot be addressed with a single offset.

Yes, you'd need extra infrastructure besides the code snippets, but
if you generate snippets for all possible offsets in advance you don't
need to patch up the snippets at all - this would make things simpler
and more portable overall.

It is actually more efficient doing a load from a constant pool rather than
encoding a big immediate in an instruction (or several instructions on a
RISC).

On what evidence do you base this claim? Why don't the compiler
writers for the PPC use this knowledge?

Basic arithmetic. Consider 64-bit constants that are repeatedly used
(such as address constants). It's obvious that it is always better to load
them from a literal pool rather than build them from multiple instructions,
both in terms of codesize and performance.

For 32-bit constants the performance gain depends on the particular
micro architecture (2 sethi/setlo instructions vs 1 load), but it is clearly
better for codesize if the constant is used more than once. I can't
speak for PPC compiler writers, but I don't know an ARM compiler that
doesn't use a literal pool.

Interestingly, the same applies to x86 and x64 - you get smaller and
potentially faster code if you use a literal pool rather than use 32-bit
and 64-bit immediates.

Silverthorne is 2-way in-order:
http://arstechnica.com/news.ars/post/20080205-small-wonder-inside-intels-silverthorne-ultramobile-cpu.html

The ARMs that go in today's high-end mobiles are mostly 1-way in-order
running at up to 750MHz using less than 500mW on 90nm. The next
generation has 2-way in-order and out-of-order cores using the same
power budget at 1GHz on 65nm.

That's a more appropriate comparison, but Silverthorne is still quite
a bit faster, so it's not surprising if it uses more power. The
article you cited says:

|Intel claims that the device has a TDP of 2 watts at 2GHz on 1.0V. At
|lower speeds, the device gets down to 0.5 watts, but it's not clear
|how far down Intel will have to ratchet the clockspeed to get there.

So overall it's not at all clear that Silverthorne consumes more power
at the same performance.

It's obvious to me that a 2-way in-order CISC is going to lose against a
2-way RISC clock for clock, so it needs to run at a higher frequency for the
same performance. Of course we'll have to wait and see until benchmarks
are run on both.

It's called Silverthorne :-) It's unlikely to be their last try, but it shows that
the x86 ISA cost cannot be overcome with a major process advantage.

One example does not prove a universal claim. And I don't even accept
your claim that this example does worse wrt power than a RISC. You
would have to compare Silverthorne with a RISC designed for similar
performance.

AMD and VIA also have low power cores, but they are not as fast or as
low power as Silverthorne. No doubt they will come out with new variants
as well, but so far nothing they produced would be suitable for a smart
phone or similar.

Concerning the process advantage, my impression is that nowadays this
is mainly in the die size (i.e., production cost) and/or transistor
count, but hardly in clock rate or power consumption; e.g., consider
the Northwood and the Prescott: the Prescott had a process advantage,
but was hardly faster and hotter.

Prescott was a special case. As I understand it, one still gets decent
transistor speed and power improvements from newer processes, just not
as big as we used to.

Wilco


.

Relevant Pages

  • Re: IBM 45nm -- new or licensed from Intel?
    ... bits, 16 bits, or 32 bits can be used, just as in most other register ... Only the multiply instructions that produce double-width results use ... Most compiler don't generate these instructions ... to a constant pool, where the offset into the constant pool is, set up ...
    (comp.arch)
  • Re: IBM 45nm -- new or licensed from Intel?
    ... set and instructions that act on them. ... Dedicate a register as constant pool pointer. ... Maintain the constant pool pointer on procedure entry and exit. ... One has to pay the register penalty of constant pools on ARM all the ...
    (comp.arch)
  • Re: IBM 45nm -- new or licensed from Intel?
    ... set and instructions that act on them. ... Dedicate a register as constant pool pointer. ... Maintain the constant pool pointer on procedure entry and exit. ... That's on a Core 2 Duo, and that's the best CPU for that benchmark I ...
    (comp.arch)
  • Re: Optimization Questions
    ... cycles you'd save would be more than offset by the cycles you'd burn ... instructions go through port 0 and port 1. ... a 16-bit register, writing one afterwards will be fast. ... Pre-read the value in EAX ...
    (comp.lang.asm.x86)
  • Re: Kind of new: function implementation questions, MASM
    ... >sub esp, varsize ... >select which of the local variables to copy into the working register, ... If you have 512kB of 8-way associative cache, ... You probably shouldn't use the prefetch instructions at all. ...
    (comp.lang.asm.x86)