23 Sep
2018
23 Sep
'18
6:37 p.m.
Its register windows have spilled out into the SCRAP heap of history.
But to its credit, the SPARCSTATION represents PANTISOCRACY with NO RACIST PAST.
It ROASTS CATNIP for SATANIC SPORT with no PARTISAN COST.
It can create a CAT SOPRANIST with a CASTRATO SNIP.
-Don
23 Sep
23 Sep
7:49 p.m.
On Sun, Sep 23, 2018, 2:37 PM Don Hopkins <don(a)donhopkins.com> wrote:
Its register windows have spilled out into the SCRAP
heap of history.
But to its credit, the SPARCSTATION represents PANTISOCRACY with NO RACIST
PAST.
It ROASTS CATNIP for SATANIC SPORT with no PARTISAN COST.
It can create a CAT SOPRANIST with a CASTRATO SNIP.
In trying to steer this word salad towards some semblance of meaningful
discussion, is SPARC dead? Practically, yes, I would say so. Or at least it
seems to be heading in that direction. Is RISC dead? Not at all. ARM is
doing quite well, and the old "CISC vs RISC" thing seems to be a non-issue
now, as even the current x86 processors have adopted many design features
that originated in RISC research.
The saddest thing about the death of SPARC, in my opinion, is that it
likely also means the death of the most advanced OS with "true" UNIX roots.
CDDL was ostensibly chosen to prevent Linux from cannibalizing the best
parts of Solaris. But it only seems to have slowed that down.
9:17 p.m.
On 9/23/18, A. P. Garcia <a.phillip.garcia(a)gmail.com> wrote:
In trying to steer this word salad towards some semblance of meaningful
discussion, is SPARC dead? Practically, yes, I would say so. Or at least it
seems to be heading in that direction. Is RISC dead? Not at all. ARM is
doing quite well, and the old "CISC vs RISC" thing seems to be a non-issue
now, as even the current x86 processors have adopted many design features
that originated in RISC research.
In general, a CISC instruction set encoding can express the same
algorithm more compactly than a RISC instruction set. Once CISC
technology solved the instruction pipelining and decoding problem, it
gained an advantage over RISC architectures such as Alpha because the
instruction set stream was less verbose. Modern x86 designs have a
bit of logic stuck in one corner that translates the x86 instruction
stream into a string of RISC-style micro-operations. The cores
execute the micro-ops. Micro-op sequences can be cached, so the
translation is done only once for loops. The result is, as it were,
the best of both worlds--the compactness of a CISC instruction stream
and the simpler and faster circuitry of RISC.
-Paul W.
24 Sep
24 Sep
11:25 a.m.
Paul Winalski <paul.winalski(a)gmail.com> wrote:
In general, a CISC instruction set encoding can express the same
algorithm more compactly than a RISC instruction set. Once CISC
technology solved the instruction pipelining and decoding problem, it
gained an advantage over RISC architectures such as Alpha because the
instruction set stream was less verbose.
It's more subtle than that, I think. One of the best contributions to this
discussion was John Mashey's classic comp.arch article (which I originally
read in 1994, I think) -
https://yarchive.net/comp/risc_definition.html
What is striking about it is that the two dominant architectures now are
(very roughly) the least CISCy CISC and the least RISCy RISC. In
particular x86 did not go in for elaborate addressing modes and highly
orthogonal instruction sets that allow you to use the elaborate addressing
modes multiple times in one instruction. (Compare it with later 68Ks, for
contrast.) So the translation to RISC-style micro-ops does not end up with
ridiculously long dependency chains within most instructions.
Tony.
--
f.anthony.n.finch <dot(a)dotat.at> http://dotat.at/
Shannon: South 3 or 4, increasing 5 to 7, perhaps gale 8 later. Moderate,
becoming rough, then very rough later in far northwest. Fair then occasional
rain. Good, becoming moderate, occasionally poor.
7:46 p.m.
On 2018-Sep-23 17:17:35 -0400, Paul Winalski <paul.winalski(a)gmail.com> wrote:
In general, a CISC instruction set encoding can express
the same
algorithm more compactly than a RISC instruction set. Once CISC
technology solved the instruction pipelining and decoding problem, it
gained an advantage over RISC architectures such as Alpha because the
instruction set stream was less verbose.
RISC architectures have another advantage that instructions are always
aligned on known boundaries (typically 2 or 4 bytes). This simplifies
the logic around (pre-)fetching instructions.
Modern x86 designs have a
bit of logic stuck in one corner that translates the x86 instruction
stream into a string of RISC-style micro-operations.
Where "modern" is "this century".
...
the best of both worlds--the compactness of a CISC
instruction stream
and the simpler and faster circuitry of RISC.
In the specific case of x86, I would dispute that. The various warts in the
x86 instruction set and "architecture" mean that x86 code density is
relatively low and on a par with SPARC code. I agree that the overall
performance is impressive but that is more a measure of the abilities of
Intel's engineers than the overall approach.
--
Peter Jeremy
8:20 p.m.
On 9/24/18, Peter Jeremy <peter(a)rulingia.com> wrote:
In the specific case of x86, I would dispute that. The various warts in
the
x86 instruction set and "architecture" mean that x86 code density is
relatively low and on a par with SPARC code. I agree that the overall
performance is impressive but that is more a measure of the abilities of
Intel's engineers than the overall approach.
No doubt about it--x86 instruction encoding is butt-ugly and wasteful,
due to the need for backward compatibility with what was originally an
8-bit architecture. Does SPARC have the vector instructions that have
been added to x86 over the years?
-Paul W.
8:45 p.m.
On 9/24/2018 4:20 PM, Paul Winalski wrote:
No doubt about it--x86 instruction encoding is
butt-ugly and wasteful,
due to the need for backward compatibility with what was originally an
8-bit architecture. Does SPARC have the vector instructions that have
been added to x86 over the years?
The 8086 was the first of the "x86"
line, which was 16-bit, although
it's I/O was more 8080-ish if I recall correctly. The 8088 was an 8-bit
data bus, granted, but having done both 8080 and 8086+ assembler, you
couldn't really tell the difference, programming-wise between the 8086
and the 8088, 16-bit registers, and all.
Cutting costs, as always, IBM opted for the 8088, which allowed them to
use an 8085-style I/O architecture.
Also, granted, to this day you can still use only 8-bits of a register:
MOV AL,0x80
art k.
26 Sep
26 Sep
6:20 a.m.
On 2018-Sep-24 16:45:13 -0400, Arthur Krewat <krewat(a)kilonet.net> wrote:
The 8086 was the first of the "x86" line,
which was 16-bit, although
it's I/O was more 8080-ish if I recall correctly.
The 8086/8088 bus was designed to be similar to the 8085 to allow 8080/8085
peripherals to support 8086 systems. This saved Intel the effort of
developing a new range of support peripherals and made it quicker for
vendors to build 8086 systems because they didn't need to wait for the
peripheral chips. There are still 8080 support chips - 8253, 8257, 8259 -
embedded in PC Southbridge chips.
The 8088 was an 8-bit
data bus, granted, but having done both 8080 and 8086+ assembler, you
couldn't really tell the difference, programming-wise between the 8086
and the 8088, 16-bit registers, and all.
This was deliberate - the 8080 was an upgraded 8008 and Intel made the 8086
similar enough to allow automated ASM translation. It seems highly likely
that the undocumented 8085 opcodes were undocumented because they weren't
readily translatable to 8086.
Cutting costs, as always, IBM opted for the 8088, which
allowed them to
use an 8085-style I/O architecture.
An 8-bit memory bus means half as many RAM chips and buffers. Keep in mind
that the IBM 5150 was intentionally crippled to ensure it didn't compete with
IBM's low-end minis.
--
Peter Jeremy
3:03 p.m.
On Wed, Sep 26, 2018 at 06:46:20AM +0000, Lars Brinkhoff wrote:
Peter Jeremy wrote:
That's not that only CPU for which this was true. The IBM PC/RT
(e.g., the 6150) CPU was originally designed to be used as a
typewriter controller. It was a RISC design which was approximately 3
times faster than a Microvax, which meant that it was quite popular
for students using MIT's Project Athenna who needed to run Scribe or
TeX/LaTeX. :-)
- Ted
the 8080 was an upgraded 8008
Also note the 8008 instruction set originated at Compuer Terminal
Corporation (later Datapoint), for use as a text terminal controller.
I'd say it's an OK design for that purpose...
3:32 p.m.
On 9/26/18, Theodore Y. Ts'o <tytso(a)mit.edu> wrote:
That's not that only CPU for which this was true. The IBM PC/RT
(e.g., the 6150) CPU was originally designed to be used as a
typewriter controller.
The CPU in the IBM 5100 was a 16-bit processor originally designed for
use in System/370 I/O peripheral controllers.
-Paul W.
3:44 p.m.
On Wed, 26 Sep 2018 at 02:21, Peter Jeremy <peter(a)rulingia.com> wrote:
An 8-bit memory bus means half as many RAM chips and buffers. Keep in mind
that the IBM 5150 was intentionally crippled to ensure it didn't compete
with
IBM's low-end minis.
Did the 5150 have a UNIX available anywhere near its launch date? I know
that it had DOS, CP/M-86, and the UCSD p-System relatively early on. It's
not clear to me whether Xenix ever supported the original PC; were there
other early porting efforts?
-Henry
6:24 p.m.
At 26 Sep 2018 15:45:25 +0000 (+00:00) from Henry Bent <henry.r.bent(a)gmail.com>om>:
Did the 5150 have a UNIX available anywhere near its
launch date? I know
that it had DOS, CP/M-86, and the UCSD p-System relatively early on. It's
not clear to me whether Xenix ever supported the original PC; were there
other early porting efforts?
read more here:
http://www.softpanorama.org/People/Torvalds/Finland_period/xenix_microsoft_…
25 Sep
25 Sep
10 a.m.
Peter Jeremy <peter(a)rulingia.com> wrote:
In the specific case of x86, I would dispute that.
The various warts in
the x86 instruction set and "architecture" mean that x86 code density is
relatively low and on a par with SPARC code.
This paper has a nice survey of instruction set densities, which very much
disagrees with your statement:
http://web.eece.maine.edu/~vweaver/papers/iccd09/iccd09_density.pdf
Tony.
--
f.anthony.n.finch <dot(a)dotat.at> http://dotat.at/
Dogger, Fisher, German Bight, Humber: West or northwest 4 backing southwest 5
to 7, occasionally gale 8 later except in Humber. Slight or moderate becoming
moderate or rough, then very rough later in Fisher. Showers. Good.
3:01 p.m.
On Tue, Sep 25, 2018 at 11:00:37AM +0100, Tony Finch wrote:
Peter Jeremy <peter(a)rulingia.com> wrote:
That's a neat paper, I like it, thanks for the pointer. I'm curious
why Peter thought what he thought, my guess would have been more like
what the paper showed, but that was a "hand optimized assembly", maybe
the compilers aren't that good? I dunno, Peter, care to comment?
In the specific case of x86, I would dispute
that. The various warts in
the x86 instruction set and "architecture" mean that x86 code density is
relatively low and on a par with SPARC code.
This paper has a nice survey of instruction set densities, which very much
disagrees with your statement:
http://web.eece.maine.edu/~vweaver/papers/iccd09/iccd09_density.pdf
7:48 p.m.
On 2018-Sep-25 08:01:52 -0700, Larry McVoy <lm(a)mcvoy.com> wrote:
On Tue, Sep 25, 2018 at 11:00:37AM +0100, Tony Finch
wrote:
I agree that looks like an interesting paper - I've skimmed it and
will have to read it in details. I was thinking back to when I was
using a mixture of SPARC and x86 at a previous job. I didn't do any
careful analysis, more eyeballing various executables and gut feeling.
I no longer have access to that environment. In view of that paper,
I'll withdraw my claim since it's not backed up by evidence.
--
Peter Jeremy
Peter Jeremy <peter(a)rulingia.com> wrote:
That's a neat paper, I like it, thanks for the pointer. I'm curious
why Peter thought what he thought, my guess would have been more like
what the paper showed, but that was a "hand optimized assembly", maybe
the compilers aren't that good? I dunno, Peter, care to comment? In the specific case of x86, I would dispute
that. The various warts in
the x86 instruction set and "architecture" mean that x86 code density is
relatively low and on a par with SPARC code.
This paper has a nice survey of instruction set densities, which very much
disagrees with your statement:
http://web.eece.maine.edu/~vweaver/papers/iccd09/iccd09_density.pdf
6:34 p.m.
On 9/25/18, Tony Finch <dot(a)dotat.at> wrote:
Peter Jeremy <peter(a)rulingia.com> wrote:
This paper has a nice survey of instruction set densities, which very much
disagrees with your statement:
http://web.eece.maine.edu/~vweaver/papers/iccd09/iccd09_density.pdf
Thanks for the pointer to that paper. Interesting reading.
There is an error in Table I (Summary of Investigated Architectures).
VAX is a pure little-endian architecture and can't operate on
big-endian data without byte swizzling. Alpha, on the other hand, can
operate either big- or little-endian (selectable at system boot time).
The version of the Intel C compiler that they used--version 9--is a
little old in the tooth. There have been several versions released
since then.
Interesting, and disappointing, that linking statically drags in the
entire C runtime. Lo-level RTLs such as libc ought to be designed to
minimize dependencies between individual library routines (e.g., if I
call only strcmp(), strcmp.o and nothing else should participate in
the static link).
As the paper points out, compilers are usually designed to optimize
for execution speed rather than code size these days.
-Paul W.
2045
days inactive
2048
days old
16 comments
11 participants
participants (11)
-
A. P. Garcia -
Arthur Krewat -
Don Hopkins -
Donald ODona -
Henry Bent -
Larry McVoy -
Lars Brinkhoff -
Paul Winalski -
Peter Jeremy -
Theodore Y. Ts'o -
Tony Finch