Introducing the AMD Sempron
A-D replaces its aging Duron fleet With a neW set
of CP5s (eres a BreakDoWn of the neW line of
BuDget processors
2004 MA XIM 13 UMPC
AMD has finally replaced
its moribund budget Duron
brand with a CPU the com-
pany hopes will smack down
Intel’s low-cost Celeron family.
Sempron processors
(adapted from semper , the
Latin word for “always”), are
currently shipping in speed
ratings of 3100+, 2800+,
2600+, 2500+, 2400+, 2300+,
and 2200+. The chips them-
selves are based on two cores:
the older K7 core used in the
Athlon XP and the current K
core used for Athlon 64 and
Athlon 64 FX.
Of the initial CPUs des-
tined for the desktop, only
the 3100+ uses the K8 core
and fits into Socket 754
motherboards. Everything
else fits into Socket A mobos.
The 3100+ ticks along at
1.8GHz and features 128KB
L1 cache and 256KB L
cache. (Current Athlon 64s
feature cache sizes of 512KB
and 1MB.) One distinct dif-
ference between the two CPU
types is 64-bit support; only
the mobile versions (3000+,
2800+, 2600+) will support64-bit operating systems.
The fastest Sempron based
on the Athlon XP core, the
Sempron 2800+, clocks in at
2GHz and has 128KB of L
cache and 256KB of L2 cache.
(In comparison, the fastest
Athlon XP, the 3200+, fea-
tures 512KB of cache.) Socket
A Semprons will also be lim-
ited to 333MHz frontside bus
speeds, whereas the 3200+
supports a 400MHz frontside
bus. But don’t get hung up
on the clock frequencies and
cache sizes—AMD says clock
speeds and cache sizes may
vary within each family of
CPU, meaning the 3100+
could have a higher clock
speed and more cache at
some point in the future.
AMD says Athlon XP and
Socket A will be supported at
least through 2005, and while
there’s been considerable
speculation that the company
would dump the Socket 754
platform, officials say further
versions of Athlon 64 for the
platform are planned.AMD and Intel are trumpeting a new security feature
built into their latest x86 processors: the NX bit. This
is like bragging about installing new locks on your
doors after having left the house wide open with a
sign out front announcing, “Burglars Welcome.”
The NX (No Execute) bit is a small but much-
needed improvement to PC security. Essentially, it
allows the processor to declare certain regions of
memory off-limits for program execution. If a program
tries to execute instructions stored in memory marked
with the NX bit, the processor’s memory-management
unit (MMU) will trigger an exception—a high-priority
error signal. The operating system will immediately
halt all other programs and terminate the offending
program, or ask if you want to terminate it.
The NX bit is a partial solution for viruses, worms,
and Trojan-horse programs that try to substitute their
own malicious instructions for genuine software code.
The attacking program invades your computer, usually
through infected e-mail, and most commonly tries to
exploit a vulnerability known as “buffer overflow.” A
buffer is a chunk of memory set aside for receiving or
sending data. By deliberately overstuffing it, the attack
overwrites some memory beyond the buffer with new
instructions. Later, when a trusted program accesses
that memory for a legitimate purpose, it is tricked into
executing the new instructions. Wham! Your computer
is now at the mercy of the attack program—unless
your system has protected the overwritten memory by
setting the NX bit. Note that the NX bit can’t prevent
the intrusion, but it can stop the sabotaged code from
running.
But while the NX bit sounds brilliant, it shouldn’t
be necessary. It’s a stopgap solution for sloppy
programming, obsolete programming languages, and
the shunning of features that were already built into
x86 processors more than 20 years ago.
Programmers deserve blame for writing crappy
code and for ignoring software tools that guard
against buffer overflows. The leading programming
languages for commercial software development
(C and C++) deserve blame because they lack the
safety of modern languages like Java and C#. And
the x86 vendors deserve blame because their early
processors, like the 8086 (1978) and 286 (1982), had
memory protection that could prevent these attacks—
but programmers didn’t like the restrictions, so later
x86 chips made the protection unnecessary.
We should be grateful for the NX bit, because it
will definitely help. But don’t be so grateful that you
kiss anyone’s feet.NX: No Excuse
for Poor Security
Tom Halfhill was formerly a senior editor for Byte magazine and
now an analyst for Microprocessor Report.▼▼FAST FORWARD BY^ TOM R. HALFHILL
Quick Start
OCTOBER 2004 MA XIMUMPC 15